gtsocial-umbx

Unnamed repository; edit this file 'description' to name the repository.
Log | Files | Refs | README | LICENSE

oidc.md (7764B)


      1 # OpenID Connect (OIDC)
      2 
      3 GoToSocial supports [OpenID Connect](https://openid.net/connect/), which is an identification protocol built on top of [OAuth 2.0](https://oauth.net/2/), an industry standard protocol for authorization.
      4 
      5 This means that you can connect GoToSocial to an external OIDC provider like [Gitlab](https://docs.gitlab.com/ee/integration/openid_connect_provider.html), [Google](https://cloud.google.com/identity-platform/docs/web/oidc), [Keycloak](https://www.keycloak.org/), or [Dex](https://dexidp.io/) and allow users to sign in to GoToSocial using their credentials for that provider.
      6 
      7 This is very convenient in the following cases:
      8 
      9 - You're running multiple services on a platform (Matrix, Peertube, GoToSocial), and you want users to be able to use the same sign in page for all of them.
     10 - You want to delegate management of users, accounts, passwords etc. to an external service to make admin easier for yourself.
     11 - You already have a lot of users in an external system and you don't want to have to recreate them all in GoToSocial manually.
     12 
     13 !!! tip
     14     If a user doesn't exist yet, login will fail if your IdP doesn't return a non-empty `email` as part of the claims. The email needs to be unique on this instance. Though we use the `sub` claim to associate the external identity with a GtS user, when a user is created it needs an email associated with it.
     15 
     16 ## Settings
     17 
     18 GoToSocial exposes the following configuration settings for OIDC, shown below with their default values.
     19 
     20 ```yaml
     21 #######################
     22 ##### OIDC CONFIG #####
     23 #######################
     24 
     25 # Config for authentication with an external OIDC provider (Dex, Google, Auth0, etc).
     26 
     27 # Bool. Enable authentication with external OIDC provider. If set to true, then
     28 # the other OIDC options must be set as well. If this is set to false, then the standard
     29 # internal oauth flow will be used, where users sign in to GtS with username/password.
     30 # Options: [true, false]
     31 # Default: false
     32 oidc-enabled: false
     33 
     34 # String. Name of the oidc idp (identity provider). This will be shown to users when
     35 # they log in.
     36 # Examples: ["Google", "Dex", "Auth0"]
     37 # Default: ""
     38 oidc-idp-name: ""
     39 
     40 # Bool. Skip the normal verification flow of tokens returned from the OIDC provider, ie.,
     41 # don't check the expiry or signature. This should only be used in debugging or testing,
     42 # never ever in a production environment as it's extremely unsafe!
     43 # Options: [true, false]
     44 # Default: false
     45 oidc-skip-verification: false
     46 
     47 # String. The OIDC issuer URI. This is where GtS will redirect users to for login.
     48 # Typically this will look like a standard web URL.
     49 # Examples: ["https://auth.example.org", "https://example.org/auth"]
     50 # Default: ""
     51 oidc-issuer: ""
     52 
     53 # String. The ID for this client as registered with the OIDC provider.
     54 # Examples: ["some-client-id", "fda3772a-ad35-41c9-9a59-f1943ad18f54"]
     55 # Default: ""
     56 oidc-client-id: ""
     57 
     58 # String. The secret for this client as registered with the OIDC provider.
     59 # Examples: ["super-secret-business", "79379cf5-8057-426d-bb83-af504d98a7b0"]
     60 # Default: ""
     61 oidc-client-secret: ""
     62 
     63 # Array of string. Scopes to request from the OIDC provider. The returned values will be used to
     64 # populate users created in GtS as a result of the authentication flow. 'openid' and 'email' are required.
     65 # 'profile' is used to extract a username for the newly created user.
     66 # 'groups' is optional and can be used to determine if a user is an admin based on oidc-admin-groups.
     67 # Examples: See eg., https://auth0.com/docs/scopes/openid-connect-scopes
     68 # Default: ["openid", "email", "profile", "groups"]
     69 oidc-scopes:
     70   - "openid"
     71   - "email"
     72   - "profile"
     73   - "groups"
     74 
     75 # Bool. Link OIDC authenticated users to existing ones based on their email address.
     76 # This is mostly intended for migration purposes if you were running previous versions of GTS
     77 # which only correlated users with their email address. Should be set to false for most usecases.
     78 # Options: [true, false]
     79 # Default: false
     80 oidc-link-existing: false
     81 
     82 # Array of string. If the returned ID token contains a 'groups' claim that
     83 # matches one of the groups in oidc-admin-groups, then this user will be granted
     84 # admin rights on the GtS instance
     85 # Default: []
     86 oidc-admin-groups: []
     87 ```
     88 
     89 ## Behavior
     90 
     91 When OIDC is enabled on GoToSocial, the default sign-in page redirects automatically to the sign-in page for the OIDC provider.
     92 
     93 This means that OIDC essentially *replaces* the normal GtS email/password sign-in flow.
     94 
     95 Due to the way the ActivityPub standard works, you _cannot_ change your username
     96 after it has been set. This conflicts with the OIDC spec which does not
     97 guarantee that the `preferred_username` field is stable.
     98 
     99 To work with this, we ask the user to provide a username on their first login
    100 attempt. The field for this is pre-filled with the value of the `preferred_username` claim.
    101 
    102 After authenticating, GtS stores the `sub` claim supplied by the OIDC provider.
    103 On subsequent authentication attempts, the user is looked up using this claim
    104 exclusively.
    105 
    106 This then allows you to change the username on a provider level without losing
    107 access to your GtS account.
    108 
    109 ### Group membership
    110 
    111 Most OIDC providers allow for the concept of groups and group memberships in returned claims. GoToSocial can use group membership to determine whether or not a user returned from an OIDC flow should be created as an admin account or not.
    112 
    113 If the returned OIDC groups information for a user contains membership of the groups configured in `oidc-admin-groups`, then that user will be created/signed in as though they are an admin.
    114 
    115 ## Migrating from old versions
    116 
    117 If you're moving from an old version of GtS which used the unstable `email`
    118 claim for unique user identification, you can set the `oidc-link-existing`
    119 configuration to `true`. If no user can be found for the ID returned by the
    120 provider, a lookup based on the `email` claim is performed instead. If this
    121 succeeds, the stable id is added to the database for the matching user.
    122 
    123 You should only use this for a limited time to avoid malicious account takeover.
    124 
    125 ## Provider Examples
    126 
    127 ### Dex
    128 
    129 [Dex](https://dexidp.io/) is an open-source OIDC Provider that you can host yourself. The procedure for installing Dex is out of scope for this documentation, but you can check out the Dex docs [here](https://dexidp.io/docs/).
    130 
    131 Dex is great because it's also written in Go, like GoToSocial, which means it's small and fast and works well on lower-powered systems.
    132 
    133 To configure Dex and GoToSocial to work together, create the following client under the `staticClients` section of your Dex config:
    134 
    135 ```yaml
    136 staticClients:
    137   - id: 'gotosocial_client'
    138     redirectURIs:
    139       - 'https://gotosocial.example.org/auth/callback'
    140     name: 'GoToSocial'
    141     secret: 'some-client-secret'
    142 ```
    143 
    144 Make sure to replace `gotosocial_client` with your desired client ID, and `secret` with a reasonably long and secure secret (a UUID for example). You should also replace `gotosocial.example.org` with the `host` of your GtS instance, but leave `/auth/callback` in place.
    145 
    146 Now, edit the `oidc` section of your GoToSocial config.yaml as follows:
    147 
    148 ```yaml
    149 oidc:
    150   enabled: true
    151   idpName: "Dex"
    152   skipVerification: false
    153   issuer: "https://auth.example.org"
    154   clientID: "gotosocial_client"
    155   clientSecret: "some-client-secret"
    156   scopes:
    157     - "openid"
    158     - "email"
    159     - "profile"
    160     - "groups"
    161 ```
    162 
    163 Make sure to replace the `issuer` variable with whatever your Dex issuer is set to. This should be the exact URI at which your Dex instance can be reached.
    164 
    165 Now, restart both GoToSocial and Dex so that the new settings are in place.
    166 
    167 When you next go to log in to GtS, you should be redirected to the sign in page for Dex. On a successful sign in, you'll be directed back to GoToSocial.