* improve scope check (log when application requests non-configured scopes) Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add offline_access special scope Signed-off-by: Jens Langhammer <jens@goauthentik.io> * ensure scope is set Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update tests for refresh tokens Signed-off-by: Jens Langhammer <jens@goauthentik.io> * special handling of scopes for github compat Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix spec Signed-off-by: Jens Langhammer <jens@goauthentik.io> * attempt to fix oidc tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * remove hardcoded slug Signed-off-by: Jens Langhammer <jens@goauthentik.io> * check scope from authorization code instead of request Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix injection for consent stage checking incorrectly Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io>
4 KiB
title |
---|
OAuth2 Provider |
This provider supports both generic OAuth2 as well as OpenID Connect
Scopes can be configured using Scope Mappings, a type of Property Mappings.
Endpoint | URL |
---|---|
Authorization | /application/o/authorize/ |
Token | /application/o/token/ |
User Info | /application/o/userinfo/ |
Token Revoke | /application/o/revoke/ |
End Session | /application/o/<application slug>/end-session/ |
JWKS | /application/o/<application slug>/jwks/ |
OpenID Configuration | /application/o/<application slug>/.well-known/openid-configuration |
GitHub Compatibility
This provider also exposes a GitHub-compatible endpoint. This endpoint can be used by applications, which support authenticating against GitHub Enterprise, but not generic OpenID Connect.
To use any of the GitHub Compatibility scopes, you have to use the GitHub Compatibility Endpoints.
Endpoint | URL |
---|---|
Authorization | /login/oauth/authorize |
Token | /login/oauth/access_token |
User Info | /user |
User Teams Info | /user/teams |
To access the user's email address, a scope of user:email
is required. To access their groups, read:org
is required. Because these scopes are handled by a different endpoint, they are not customisable as a Scope Mapping.
Grant types
authorization_code
:
This grant is used to convert an authorization code to an access token (and optionally refresh token). The authorization code is retrieved through the Authorization flow, and can only be used once, and expires quickly.
:::info
Starting with authentik 2024.1, applications only receive an access token. To receive a refresh token, applications must be allowed to request the offline_access
scope in authentik and also be configured to request the scope.
:::
refresh_token
:
Refresh tokens can be used as long-lived tokens to access user data, and further renew the refresh token down the road.
:::info
Starting with authentik 2024.1, this grant requires the offline_access
scope.
:::
client_credentials
:
See Machine-to-machine authentication
Scope authorization
By default, every user that has access to an application can request any of the configured scopes. Starting with authentik 2022.4, you can do additional checks for the scope in an expression policy (bound to the application):
# There are additional fields set in the context, use `ak_logger.debug(request.context)` to see them.
if "my-admin-scope" in request.context["oauth_scopes"]:
return ak_is_group_member(request.user, name="my-admin-group")
return True
Special scopes
GitHub compatibility
user
: No-op, is accepted for compatibility but does not give access to any resourcesread:user
: Same as aboveuser:email
: Allows read-only access to/user
, including email addressread:org
: Allows read-only access to/user/teams
, listing all the user's groups as teams.
authentik
goauthentik.io/api
: This scope grants the refresh token access to the authentik API on behalf of the user
Default scopes
:::info Requires authentik 2022.7 :::
When a client does not request any scopes, authentik will treat the request as if all configured scopes were requested. Depending on the configured authorization flow, consent still needs to be given, and all scopes are listed there.
This does not apply to special scopes, as those are not configurable in the provider.