Use as remote MCP server with an oauth application

[elee1766]

It would be useful to perhaps allow running the mcp as a remote mcp server pointed at an instance, and then users when they connect to it, authorize with the gitlab instance/application, using that token for auth.

this way, people dont have to generate a token in order to use MCP with our gitlab instance, and ideally I just setup the MCP server with an application once for myself.

Are there any plans / interest in this sort of feature?

[iwakitakuma33]

@elee1766

Is it correct that what you are imagining is not to use a token issued by an individual, but to use a token issued by gitlab via mcp through the authentication screen as follows?

json of cursor or claude with sse
Authorization: Bearer

[mtesch-um]

I guess the idea they're trying to suggest is to create the server as an "application" in gitlab (user or group level)

• https://docs.gitlab.com/integration/oauth_provider/

and then let the user log in via oauth to grant the server access to their own resources via

• https://docs.gitlab.com/api/oauth2/

[elee1766]

yeah sorry i couldn't describe it better. @iwakitakuma33 it is exactly @mtesch-um says.

so a remote mcp server is supposed to act as a oauth 2.1 resource server and so there is some standardization of auth here.

a big advantage of this would be that i could setup a server like - "https://mcp.mygitlabinstance.com" and then all users of mygitlabinstance.com could use the mcp, simply by configuring that remote url as their mcp, instead of needing to install the gitlab mcp directly, and configure.

see the github mcp server which can do this with oauth: https://github.com/github/github-mcp-server

[AndrewFarley]

Note: The (lack of) this make this project unusable for my purposes. And, well, I don't want to pay for Duo to get this. Anyone interested in adding this? I could offer a bounty?

[iwakitakuma33]

@AndrewFarley
OK.
I add it.

@elee1766

IIf you have an environment where you can test the functionality after adding it, please let us know.

[elee1766]

@iwakitakuma33

im trying to add this feature myself since i really want it

having to change a lot about how auth works though, and im restructuring some stuff as i do it.

im working on it here: https://github.com/elee1766/gitlab-mcp/tree/proxy_oauth

if you want to do it though im happy to just stop

[AndrewFarley]

I see the beginnings of greatness in your work elee, keep it up. :) If you get it working and need someone to test I could have a go. And if/when it's audited/merged here, hit me up I'll be happy to ship you a gift card or some crypto friend.

[iwakitakuma33]

@AndrewFarley No thank you but I appreciate your kindness

If I need a job I'll talk to you.

cas
I don't own this repository. I use it for my own convenience. I've worked in company with a variety of free software.

[elee1766]

@AndrewFarley

so this is actually sort of an involved task, because the gitlab oauth API doesn't seem to support dynamic client registration which is required for most mcp consumers to auto configure themselves.

I see this as a two step process now

1. allow running the gitlab mcp server in such. a way that a user can pass their own API key in a custom header (or maybe even just the gitlab default header) and this API key is forwarded to the ultimate request made to gitlab api (so you can have user scoped requests)

2. implement a oauth2 server which implements dcr on top of an existing application, which would require some sort of small persistence layer. clients would auth with this proxy server, be able to get a gitlab oauth2 user scoped token supposedly, and that token would be passed to agent commands using the same mechanism as step 1

let me know what you think. I will likely get a working MVP for step 1 soon

edit: ok you can try to use GITLAB_PAT_PASSTHROUGH="true" and this maybe will work? same branch

https://github.com/elee1766/gitlab-mcp/tree/proxy_oauth

[elee1766]

@AndrewFarley ok actually i pushed this absolutely awful please do not trust this with anything or to do anything proxy which implements DCR on top of an oauth2 server that does not support it.

feel free to try it lmao. i need to do some reading and figure out if this is even allowed/secure, and then move the storage backend to something that isnt memory.

i have no clue how many rules im breaking and if this entire like auth scheme is spoofable so please at your own risk

but hey it worked for me in claude code.

SSE="true"
PORT=3002
GITLAB_API_URL="<gitlab_url>"

GITLAB_OAUTH2_AUTHORIZATION_URL= "<gitlab_url>/oauth/authorize"
GITLAB_OAUTH2_REVOCATION_URL="<gitlab_url>/oauth/revoke"
GITLAB_OAUTH2_TOKEN_URL="<gitlab_url>/oauth/token"
GITLAB_OAUTH2_INTROSPECTION_URL="<gitlab_url>/oauth/introspect"


GITLAB_OAUTH2_BASE_URL="http://localhost:3002"
GITLAB_OAUTH2_ISSUER_URL="https://<gitlab_url>"

GITLAB_OAUTH2_REDIRECT_URL="http://localhost:3002/callback"
GITLAB_OAUTH2_CLIENT_ID="<client id>"
GITLAB_OAUTH2_CLIENT_SECRET="<client secret>"

good luck!

[AndrewFarley]

I see this as a two step process now

allow running the gitlab mcp server in such. a way that a user can pass their own API key in a custom header (or maybe even just the gitlab default header) and this API key is forwarded to the ultimate request made to gitlab api (so you can have user scoped requests)

implement a oauth2 server which implements dcr on top of an existing application, which would require some sort of small persistence layer. clients would auth with this proxy server, be able to get a gitlab oauth2 user scoped token supposedly, and that token would be passed to agent commands using the same mechanism as step 1

I could see doing either of these. I just don't know if there's some MCP-specific auth (eg: oauth) that MUST be implemented and is more compatible with MCP clients out there. But, to me, that first one seems a lot easier. A user could generate their own PAT and then send that PAT with every request to the proxy, which the proxy would "act as them" for their requests. To me, that seems the simplest, but again, I'm not sure if there's some compatibility issues with some clients (eg: VS Code) where it might not let you specify a custom header/cookie/url param which would contain the PAT.

Having said that, the second option seems a lot more secure and maybe the ideal implementation

[elee1766]

@AndrewFarley yeah so both of these are implemented. as ive said i dont' feel that great about oauth but i feel pretty good about the api token passthrough.

[bdoyle0182]

I wouldn't consider token passthrough secure or the right method with the latest MCP spec and oauth support. We should definitely get to option 2 as that's the correct way to do this now with the current mcp spec now that they are oauth resource servers and deprecate concept of token passthrough

[elee1766]

I wouldn't consider token passthrough secure or the right method with the latest MCP spec and oauth support. We should definitely get to option 2 as that's the correct way to do this now with the current mcp spec now that they are oauth resource servers and deprecate concept of token passthrough

yeah i implemented option 2 in the pr

[Geod24]

Subscribing because I also have an interest in this (as would anyone trying to productionize this I assume!).
Thanks for your work here @elee1766 , is there anything we can do to help with #130 ?