OAuth2 - Additional Scopes Not Recognized For Required Claim Name/Value

[MAXimized490]

Description

Configuring the Discord OAuth2 authentication provider works without issues until you try to restrict login with additional scopes.

Here is a basic configuration of the Discord provider:
Client ID: <your app id>
Client Secret: <your app secret>
Additional Scopes: guilds

Using this configuration, users are able to login/register via Discord without issues. Now lets try to restrict login to server membership. Looking at the Discord API docs, we see that the guilds scope will provide an id claim with the value being the server's ID. With this, we should be able to specify the necessary values.

Client ID: <your app id>
Client Secret: <your app secret>
Additional Scopes: guilds
Required Claim Name: id
Required Claim Value: <server id>

This will fail, resulting in the "Sign In Prohibited - Your account is prohibited from signing in, please contact your site administrator." Various alternate configurations of these values have been tried and none of them work. Because these values nor the countless I've tried have worked, I am opening this issue because either I am incorrectly configuring these settings or Gitea is not parsing the API response properly.

One thing of note is that the description for the Required Claim Value reads, "Set this value to restrict login from this source to users with a claim with this name and value." I cannot tell whether this description is purposefully worded this way, as I would assume this doesn't make sense when I can specify a required claim name separately. Regardless, trying to enter the entire claim or just the value here does not work either.

Quick Note on Logs
Logs were copied after a fresh start of the docker container and then attempting to sign in with Discord with the required claim fields filled out. Since users are able to sign in when these fields are empty, I assume those logs are irrelevant.

Gitea Version

1.22.1

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

https://gist.github.com/MAXimized490/c61f693111bc764389ca449cf3c5c6fb

Screenshots

Again, just a reminder that registration/login will work when the required claim fields are left blank.

Git Version

2.45.2

Operating System

Docker on Ubuntu Server 22.04

How are you running Gitea?

Using the official docker image via docker-compose on Portainer. Below is my compose file.

version: "3"

networks:
  gitea:
    external: false
  CENSORED:
    external: true

services:
  server:
    image: gitea/gitea:1.22.1
    container_name: gitea
    environment:
      - USER_UID=1000
      - USER_GID=1000
      - GITEA__database__DB_TYPE=mysql
      - GITEA__database__HOST=db:3306
      - GITEA__database__NAME=gitea
      - GITEA__database__USER=CENSORED
      - GITEA__database__PASSWD=CENSORED

    restart: always
    networks:
      gitea:
      CENSORED:
        ipv4_address: CENSORED
    volumes:
      - gitea-data:/data
      - /etc/timezone:/etc/timezone:ro
      - /etc/localtime:/etc/localtime:ro
    ports:
      - "CENSORED:3000"
#      - "222:22"
    depends_on:
      - db

  db:
    image: mysql:8.0-oraclelinux8
    restart: always
    environment:
      - MYSQL_ROOT_PASSWORD=CENSORED
      - MYSQL_USER=CENSORED
      - MYSQL_PASSWORD=CENSORED
      - MYSQL_DATABASE=gitea
    networks:
      - gitea
    volumes:
      - gitea-mysql:/var/lib/mysql

volumes:
  gitea-data:
  gitea-mysql:

Database

MySQL/MariaDB

[MAXimized490]

After testing further, I have determined that setting the required claim name to id and the required claim value to a user's ID will successfully restrict login to that specific user. I still can't see how one is supposed to grab the claim name from the guilds scope since it also uses "id" as the name.

[MAXimized490]

I did some further testing.

By default, Gitea will request the identify and email scopes. Setting Required Claim Name to any claim name expected within these scopes will work without issue. Going further and adding a Required Claim Value will again work as expected, limiting login to those with matching claims.

It's clear that adding guilds to the Additional Scopes (shown in original post) works because the Discord access request page will show that the application is requesting to see what servers the user is in, and removing guilds from Additional Scopes will make this disappear.

We can reliably test whether the guilds scope is working so long as we only use the identify, email, and guilds scopes. This is because the guilds scope has a few unique claims, notably "icon: "<fileID>" and "owner": "<bolean>". We've already determined that we can reliably test whether a scope's claims are being detected by simply setting the Required Scope Name and leaving the Required Scope Value blank. Trying this with icon or owner does not work, indicating that Gitea is not seeing these claims. Again, setting these back to a claim name from identify/email will work as expected.

[lunny]

Related to #32573

[marcellmars]

did you try to set required claimed name to name
and then required claimed value just the name of the guild (as in string)?

[marcellmars]

Related to #32573

i think this is the flow when gitea allows discord's user to login into gitea. and the attempt is to reduce the logins to the users with the membership of specific guild.

#32573 is the other way around when third party relies on gitea for the check if user could login or not.

it's very confusing because the vocabulary is the same. i'm very interested if i got this wrong and if this is related to #32573 so i have to change something there ;)

[MAXimized490]

@marcellmars Thanks for your reply and I'm sorry I am responding so late. I ended up using Authentik in my environment and dropped trying to support Discord SSO directly from Gitea. I might try and mess with it later to see if using that configuration will work, but I've more or less dropped this issue. Hopefully others can chime in. Thanks again!

[ohanf]

I ran into this same use-case + problem, and from skimming some code I'm not sure what the best course of action would be as the "issue" is not entirely Gitea owned code.

As I understand it having the guilds scope does not change the returned user object from Discord's normal OIDC endpoint /users/@me. The fields from that endpoint are the ones that we can match on today in the "required claim" settings. What the guilds scope does allow you to do is access the /users/@me/guilds endpoint which will then return the list of all guilds the currently authenticated user is a part of.

From a quick read here is what is happening:

• Gitea is simply vending out the oauth implementation to the Goth library (generally a good idea to not implement authentication if you do not have to):

  gitea/services/auth/source/oauth2/providers_simple.go

  Lines 85 to 88 in 2e42e96

  	RegisterGothProvider(NewSimpleProvider("discord", "Discord", []string{discord.ScopeIdentify, discord.ScopeEmail},
  	func(clientKey, secret, callbackURL string, scopes ...string) goth.Provider {
  	return discord.New(clientKey, secret, callbackURL, scopes...)
  	}))

• Goth aggregates a ton of providers, one of which is obviously Discord: https://github.com/markbates/goth/blob/b1c5727cb5a7e3a9ef4aa2cd7825590d3d11a6af/providers/discord/discord.go#L112
• The Discord provider, like every Goth provider, only returns a goth.User object: https://github.com/markbates/goth/blob/b1c5727cb5a7e3a9ef4aa2cd7825590d3d11a6af/user.go#L14-L31 which does not include any information about group membership, although if a backend provider does return that information, it could be found in the RawData field.
• Since Gitea itself is mostly just wrapping / proxying these Goth User objects, all we have access to is that basic user information.

So, if we want access to the groups/guilds, a few things would need to happen:

• Someone needs to make the request to /users/@me/guilds, either somewhere in the Gitea wrapper, or upstreamed into Goth itself. A small optimization since this adds a request round trip of overhead would be to only make this request when the guilds claim is present.
• Regardless of where in the authentication chain the request is made, we would have to attach the groups (aka guild) information to the user object, probably by inserting into that RawData struct field, but using some reasonable schema to avoid conflicts in the future.
• Finally, since the guild objects are from their own request and thus have their own structure (and are presumably nested within the user), we would have to figure out a matching syntax that would allow for matching on that nested object.
• I didn't look at any other providers, but it may make sense instead of the above bullet to just slap together a custom UI for when the Discord provider is being used to make the matching / selection more intuitive.

I'd love to help with implementation, but I am not familiar with the Gitea codebase nor the design decisions/philosophy of the maintainers. I'm also not clear on how much free time I would have to assist. Fortunately I think the hardest part of implementing this fix is deciding how the new request/data should fit into the current pipeline, actually making an extra HTTP request is generally pretty easy :)

Hopefully at a minimum my investigation / explanation here is helpful in understanding the problem and getting the ball rolling!