Authlib
Authlib
This section contains the generic implementation of RFC6749. You should read Introduce OAuth 2.0 at first. Here are some tips:
Have a better understanding of OAuth 2.0
How to use OAuth 2 Session for Requests
How to implement Flask OAuth Client
How to implement Flask OAuth 2.0 Server
How to implement Django OAuth Client
How to implement Django OAuth 2.0 Server
Here are the API references for developers. For framework level interfaces, check:
Authorization server that handles Authorization Endpoint and Token Endpoint.
scopes_supported – A list of supported scopes by this authorization server.
Authenticate client via HTTP request information with the given
methods, such as client_secret_basic, client_secret_post.
Validate authorization request and create authorization response.
request – HTTP request instance.
grant_user – if granted, it is resource owner. If denied, it is None.
Response
Validate endpoint request and create endpoint response.
name – Endpoint name
request – HTTP request instance.
Response
This method MUST be implemented in framework integrations. It is used to create an HttpRequest instance.
request – the “request” instance in framework
HttpRequest instance
This method MUST be implemented in framework integrations. It is used to create an OAuth2Request instance.
request – the “request” instance in framework
OAuth2Request instance
Validate token request and create token response.
request – HTTP request instance
Generate the token dict.
grant_type – current requested grant_type.
client – the client that making the request.
user – current authorized user.
expires_in – if provided, use this value as expires_in.
scope – current requested scope.
include_refresh_token – should refresh_token be included.
Token dict
Find the authorization grant for current request.
request – OAuth2Request instance.
grant instance
Validate current HTTP request for authorization page. This page is designed for resource owner to grant or deny the authorization.
Return a URI for the given error, framework may implement this method.
Find the token grant for current request.
request – OAuth2Request instance.
grant instance
Return HTTP response. Framework MUST implement this function.
Query OAuth client by client_id. The client model class MUST
implement the methods described by
ClientMixin.
Add more client auth method. The default methods are:
none: The client is a public client and does not have a client secret
client_secret_post: The client uses the HTTP POST parameters
client_secret_basic: The client uses HTTP Basic
method – Name of the Auth method
func – Function to authenticate the client
The auth method accept two parameters: query_client and request,
an example for this method:
def authenticate_client_via_custom(query_client, request):
client_id = request.headers['X-Client-Id']
client = query_client(client_id)
do_some_validation(client)
return client
authorization_server.register_client_auth_method(
'custom', authenticate_client_via_custom)
Add extra endpoint to authorization server. e.g. RevocationEndpoint:
authorization_server.register_endpoint(RevocationEndpoint)
endpoint_cls – A endpoint class
Register a grant class into the endpoint registry. Developers
can implement the grants in authlib.oauth2.rfc6749.grants and
register with this method:
class AuthorizationCodeGrant(grants.AuthorizationCodeGrant):
def authenticate_user(self, credential):
# ...
authorization_server.register_grant(AuthorizationCodeGrant)
grant_cls – a grant class.
extensions – extensions for the grant class.
Register a function as token generator for the given grant_type.
Developers MUST register a default token generator with a special
grant_type=default:
def generate_bearer_token(grant_type, client, user=None, scope=None,
expires_in=None, include_refresh_token=True):
token = {'token_type': 'Bearer', 'access_token': ...}
if include_refresh_token:
token['refresh_token'] = ...
...
return token
authorization_server.register_token_generator('default', generate_bearer_token)
If you register a generator for a certain grant type, that generator will only works for the given grant type:
authorization_server.register_token_generator('client_credentials', generate_bearer_token)
grant_type – string name of the grant type
func – a function to generate token
Define function to save the generated token into database.
Framework integration can re-implement this method to support signal system.
Validate if requested scope is supported by Authorization Server. Developers CAN re-write this method to meet your needs.
Get token validator from registry for the given token type.
Parse the token and token validator from request Authorization header. Here is an example of Authorization header:
Authorization: Bearer a-token-string
This method will parse this header, if it can find the validator for
Bearer, it will return the validator and a-token-string.
validator, token_string
MissingAuthorizationError
UnsupportedTokenTypeError
Register a token validator for a given Authorization type. Authlib has a built-in BearerTokenValidator per rfc6750.
Validate the request and return a token.
Implementation of OAuth 2 Client described in Section 2 with some methods to help validation. A client has at least these information:
client_id: A string represents client identifier.
client_secret: A string represents client password.
endpoint.
Check client_secret matching with the client. For instance, in
the client table, the column is called client_secret:
import secrets
def check_client_secret(self, client_secret):
return secrets.compare_digest(self.client_secret, client_secret)
client_secret – A string of client secret
bool
Check if client support the given method for the given endpoint.
There is a token_endpoint_auth_method defined via RFC7591.
Developers MAY re-implement this method with:
def check_endpoint_auth_method(self, method, endpoint):
if endpoint == 'token':
# if client table has ``token_endpoint_auth_method``
return self.token_endpoint_auth_method == method
return True
Method values defined by this specification are:
and does not have a client secret.
as defined in OAuth 2.0
OAuth 2.0
Validate if the client can handle the given grant_type. There are four grant types defined by RFC6749:
authorization_code
implicit
client_credentials
password
For instance, there is a allowed_grant_types column in your client:
def check_grant_type(self, grant_type):
return grant_type in self.grant_types
grant_type – the requested grant_type string.
bool
Validate redirect_uri parameter in Authorization Endpoints. For
instance, in the client table, there is an allowed_redirect_uris
column:
def check_redirect_uri(self, redirect_uri):
return redirect_uri in self.allowed_redirect_uris
redirect_uri – A URL string for redirecting.
bool
Validate if the client can handle the given response_type. There
are two response types defined by RFC6749: code and token. For
instance, there is a allowed_response_types column in your client:
def check_response_type(self, response_type):
return response_type in self.response_types
response_type – the requested response_type string.
bool
A method to return a list of requested scopes which are supported by
this client. For instance, there is a scope column:
def get_allowed_scope(self, scope):
if not scope:
return ''
allowed = set(scope_to_list(self.scope))
return list_to_scope([s for s in scope.split() if s in allowed])
scope – the requested scope.
string of scope
A method to return client_id of the client. For instance, the value
in database is saved in a column called client_id:
def get_client_id(self):
return self.client_id
string
A method to get client default redirect_uri. For instance, the
database table for client has a column called default_redirect_uri:
def get_default_redirect_uri(self):
return self.default_redirect_uri
A URL string
A method to get authorization code’s redirect_uri.
For instance, the database table for authorization code has a
column called redirect_uri:
def get_redirect_uri(self):
return self.redirect_uri
A URL string
A method to get scope of the authorization code. For instance,
the column is called scope:
def get_scope(self):
return self.scope
scope string
A method to check if this token is issued to the given client.
For instance, client_id is saved on token table:
def check_client(self, client):
return self.client_id == client.client_id
bool
A method to get the expires_in value of the token. e.g.
the column is called expires_in:
def get_expires_in(self):
return self.expires_in
timestamp int
A method to get scope of the authorization code. For instance,
the column is called scope:
def get_scope(self):
return self.scope
scope string
A method to define if this token is expired. For instance,
there is a column expired_at in the table:
def is_expired(self):
return self.expired_at < now
boolean
A method to define if this token is revoked. For instance,
there is a boolean column revoked in the table:
def is_revoked(self):
return self.revoked
boolean
Get a list of body.
Check and raise InsecureTransportError with the given URI.
The request is missing a required parameter, includes an unsupported parameter value (other than grant type), repeats a parameter, includes multiple credentials, utilizes more than one mechanism for authenticating the client, or is otherwise malformed.
Client authentication failed (e.g., unknown client, no client authentication included, or unsupported authentication method). The authorization server MAY return an HTTP 401 (Unauthorized) status code to indicate which HTTP authentication schemes are supported. If the client attempted to authenticate via the “Authorization” request header field, the authorization server MUST respond with an HTTP 401 (Unauthorized) status code and include the “WWW-Authenticate” response header field matching the authentication scheme used by the client.
The provided authorization grant (e.g., authorization code, resource owner credentials) or refresh token is invalid, expired, revoked, does not match the redirection URI used in the authorization request, or was issued to another client.
The authenticated client is not authorized to use this authorization grant type.
The authorization grant type is not supported by the authorization server.
The requested scope is invalid, unknown, malformed, or exceeds the scope granted by the resource owner.
The resource owner or authorization server denied the request.
Used in authorization endpoint for “code” and “implicit”. Defined in Section 4.1.2.1.
The authorization code grant type is used to obtain both access tokens and refresh tokens and is optimized for confidential clients. Since this is a redirection-based flow, the client must be capable of interacting with the resource owner’s user-agent (typically a web browser) and capable of receiving incoming requests (via redirection) from the authorization server:
+----------+
| Resource |
| Owner |
| |
+----------+
^
|
(B)
+----|-----+ Client Identifier +---------------+
| -+----(A)-- & Redirection URI ---->| |
| User- | | Authorization |
| Agent -+----(B)-- User authenticates --->| Server |
| | | |
| -+----(C)-- Authorization Code ---<| |
+-|----|---+ +---------------+
| | ^ v
(A) (C) | |
| | | |
^ v | |
+---------+ | |
| |>---(D)-- Authorization Code ---------' |
| Client | & Redirection URI |
| | |
| |<---(E)----- Access Token -------------------'
+---------+ (w/ Optional Refresh Token)
Allowed client auth methods for token endpoint
Generated “code” length
The client constructs the request URI by adding the following parameters to the query component of the authorization endpoint URI using the “application/x-www-form-urlencoded” format. Per Section 4.1.1.
REQUIRED. Value MUST be set to “code”.
REQUIRED. The client identifier as described in Section 2.2.
OPTIONAL. As described in Section 3.1.2.
OPTIONAL. The scope of the access request as described by Section 3.3.
RECOMMENDED. An opaque value used by the client to maintain state between the request and callback. The authorization server includes this value when redirecting the user-agent back to the client. The parameter SHOULD be used for preventing cross-site request forgery as described in Section 10.12.
The client directs the resource owner to the constructed URI using an HTTP redirection response, or by other means available to it via the user-agent.
For example, the client directs the user-agent to make the following HTTP request using TLS (with extra line breaks for display purposes only):
GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
Host: server.example.com
The authorization server validates the request to ensure that all required parameters are present and valid. If the request is valid, the authorization server authenticates the resource owner and obtains an authorization decision (by asking the resource owner or by establishing approval via other means).
If the resource owner grants the access request, the authorization server issues an authorization code and delivers it to the client by adding the following parameters to the query component of the redirection URI using the “application/x-www-form-urlencoded” format. Per Section 4.1.2.
REQUIRED. The authorization code generated by the authorization server. The authorization code MUST expire shortly after it is issued to mitigate the risk of leaks. A maximum authorization code lifetime of 10 minutes is RECOMMENDED. The client MUST NOT use the authorization code more than once. If an authorization code is used more than once, the authorization server MUST deny the request and SHOULD revoke (when possible) all tokens previously issued based on that authorization code. The authorization code is bound to the client identifier and redirection URI.
REQUIRED if the “state” parameter was present in the client authorization request. The exact value received from the client.
For example, the authorization server redirects the user-agent by sending the following HTTP response.
HTTP/1.1 302 Found
Location: https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA
&state=xyz
redirect_uri – Redirect to the given URI for the authorization
grant_user – if resource owner granted the request, pass this resource owner, otherwise pass None.
(status_code, body, headers)
The client makes a request to the token endpoint by sending the following parameters using the “application/x-www-form-urlencoded” format per Section 4.1.3:
REQUIRED. Value MUST be set to “authorization_code”.
REQUIRED. The authorization code received from the authorization server.
REQUIRED, if the “redirect_uri” parameter was included in the authorization request as described in Section 4.1.1, and their values MUST be identical.
REQUIRED, if the client is not authenticating with the authorization server as described in Section 3.2.1.
If the client type is confidential or the client was issued client credentials (or assigned other authentication requirements), the client MUST authenticate with the authorization server as described in Section 3.2.1.
For example, the client makes the following HTTP request using TLS:
POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
If the access token request is valid and authorized, the authorization server issues an access token and optional refresh token as described in Section 5.1. If the request client authentication failed or is invalid, the authorization server returns an error response as described in Section 5.2. Per Section 4.1.4.
An example successful response:
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache
{
"access_token":"2YotnFZFEjr1zCsicMWpAA",
"token_type":"example",
"expires_in":3600,
"refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
"example_parameter":"example_value"
}
(status_code, body, headers)
“The method to generate “code” value for authorization code data. Developers may rewrite this method, or customize the code length with:
class MyAuthorizationCodeGrant(AuthorizationCodeGrant):
AUTHORIZATION_CODE_LENGTH = 32 # default is 48
Save authorization_code for later use. Developers MUST implement it in subclass. Here is an example:
def save_authorization_code(self, code, request):
client = request.client
item = AuthorizationCode(
code=code,
client_id=client.client_id,
redirect_uri=request.redirect_uri,
scope=request.scope,
user_id=request.user.id,
)
item.save()
Get authorization_code from previously savings. Developers MUST implement it in subclass:
def query_authorization_code(self, code, client):
return Authorization.get(code=code, client_id=client.client_id)
code – a string represent the code.
client – client related to this code.
authorization_code object
Delete authorization code from database or cache. Developers MUST implement it in subclass, e.g.:
def delete_authorization_code(self, authorization_code):
authorization_code.delete()
authorization_code – the instance of authorization_code
Authenticate the user related to this authorization_code. Developers MUST implement this method in subclass, e.g.:
def authenticate_user(self, authorization_code):
return User.query.get(authorization_code.user_id)
authorization_code – AuthorizationCode object
user
The implicit grant type is used to obtain access tokens (it does not support the issuance of refresh tokens) and is optimized for public clients known to operate a particular redirection URI. These clients are typically implemented in a browser using a scripting language such as JavaScript.
Since this is a redirection-based flow, the client must be capable of interacting with the resource owner’s user-agent (typically a web browser) and capable of receiving incoming requests (via redirection) from the authorization server.
Unlike the authorization code grant type, in which the client makes separate requests for authorization and for an access token, the client receives the access token as the result of the authorization request.
The implicit grant type does not include client authentication, and relies on the presence of the resource owner and the registration of the redirection URI. Because the access token is encoded into the redirection URI, it may be exposed to the resource owner and other applications residing on the same device:
+----------+
| Resource |
| Owner |
| |
+----------+
^
|
(B)
+----|-----+ Client Identifier +---------------+
| -+----(A)-- & Redirection URI --->| |
| User- | | Authorization |
| Agent -|----(B)-- User authenticates -->| Server |
| | | |
| |<---(C)--- Redirection URI ----<| |
| | with Access Token +---------------+
| | in Fragment
| | +---------------+
| |----(D)--- Redirection URI ---->| Web-Hosted |
| | without Fragment | Client |
| | | Resource |
| (F) |<---(E)------- Script ---------<| |
| | +---------------+
+-|--------+
| |
(A) (G) Access Token
| |
^ v
+---------+
| |
| Client |
| |
+---------+
authorization_code grant type has authorization endpoint
Allowed client auth methods for token endpoint
The client constructs the request URI by adding the following parameters to the query component of the authorization endpoint URI using the “application/x-www-form-urlencoded” format. Per Section 4.2.1.
REQUIRED. Value MUST be set to “token”.
REQUIRED. The client identifier as described in Section 2.2.
OPTIONAL. As described in Section 3.1.2.
OPTIONAL. The scope of the access request as described by Section 3.3.
RECOMMENDED. An opaque value used by the client to maintain state between the request and callback. The authorization server includes this value when redirecting the user-agent back to the client. The parameter SHOULD be used for preventing cross-site request forgery as described in Section 10.12.
The client directs the resource owner to the constructed URI using an HTTP redirection response, or by other means available to it via the user-agent.
For example, the client directs the user-agent to make the following HTTP request using TLS:
GET /authorize?response_type=token&client_id=s6BhdRkqt3&state=xyz
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
Host: server.example.com
If the resource owner grants the access request, the authorization server issues an access token and delivers it to the client by adding the following parameters to the fragment component of the redirection URI using the “application/x-www-form-urlencoded” format. Per Section 4.2.2.
REQUIRED. The access token issued by the authorization server.
REQUIRED. The type of the token issued as described in Section 7.1. Value is case insensitive.
RECOMMENDED. The lifetime in seconds of the access token. For example, the value “3600” denotes that the access token will expire in one hour from the time the response was generated. If omitted, the authorization server SHOULD provide the expiration time via other means or document the default value.
OPTIONAL, if identical to the scope requested by the client; otherwise, REQUIRED. The scope of the access token as described by Section 3.3.
REQUIRED if the “state” parameter was present in the client authorization request. The exact value received from the client.
The authorization server MUST NOT issue a refresh token.
For example, the authorization server redirects the user-agent by sending the following HTTP response:
HTTP/1.1 302 Found
Location: http://example.com/cb#access_token=2YotnFZFEjr1zCsicMWpAA
&state=xyz&token_type=example&expires_in=3600
Developers should note that some user-agents do not support the inclusion of a fragment component in the HTTP “Location” response header field. Such clients will require using other methods for redirecting the client than a 3xx redirection response – for example, returning an HTML page that includes a ‘continue’ button with an action linked to the redirection URI.
redirect_uri – Redirect to the given URI for the authorization
grant_user – if resource owner granted the request, pass this resource owner, otherwise pass None.
(status_code, body, headers)
The resource owner password credentials grant type is suitable in cases where the resource owner has a trust relationship with the client, such as the device operating system or a highly privileged
application. The authorization server should take special care when enabling this grant type and only allow it when other flows are not viable.
This grant type is suitable for clients capable of obtaining the resource owner’s credentials (username and password, typically using an interactive form). It is also used to migrate existing clients using direct authentication schemes such as HTTP Basic or Digest authentication to OAuth by converting the stored credentials to an access token:
+----------+
| Resource |
| Owner |
| |
+----------+
v
| Resource Owner
(A) Password Credentials
|
v
+---------+ +---------------+
| |>--(B)---- Resource Owner ------->| |
| | Password Credentials | Authorization |
| Client | | Server |
| |<--(C)---- Access Token ---------<| |
| | (w/ Optional Refresh Token) | |
+---------+ +---------------+
The client makes a request to the token endpoint by adding the following parameters using the “application/x-www-form-urlencoded” format per Appendix B with a character encoding of UTF-8 in the HTTP request entity-body:
REQUIRED. Value MUST be set to “password”.
REQUIRED. The resource owner username.
REQUIRED. The resource owner password.
OPTIONAL. The scope of the access request as described by Section 3.3.
If the client type is confidential or the client was issued client credentials (or assigned other authentication requirements), the client MUST authenticate with the authorization server as described in Section 3.2.1.
For example, the client makes the following HTTP request using transport-layer security (with extra line breaks for display purposes only):
POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded
grant_type=password&username=johndoe&password=A3ddj3w
If the access token request is valid and authorized, the authorization server issues an access token and optional refresh token as described in Section 5.1. If the request failed client authentication or is invalid, the authorization server returns an error response as described in Section 5.2.
An example successful response:
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache
{
"access_token":"2YotnFZFEjr1zCsicMWpAA",
"token_type":"example",
"expires_in":3600,
"refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
"example_parameter":"example_value"
}
(status_code, body, headers)
validate the resource owner password credentials using its existing password validation algorithm:
def authenticate_user(self, username, password):
user = get_user_by_username(username)
if user.check_password(password):
return user
The client can request an access token using only its client credentials (or other supported means of authentication) when the client is requesting access to the protected resources under its control, or those of another resource owner that have been previously arranged with the authorization server.
The client credentials grant type MUST only be used by confidential clients:
+---------+ +---------------+
| | | |
| |>--(A)- Client Authentication --->| Authorization |
| Client | | Server |
| |<--(B)---- Access Token ---------<| |
| | | |
+---------+ +---------------+
https://tools.ietf.org/html/rfc6749#section-4.4
The client makes a request to the token endpoint by adding the following parameters using the “application/x-www-form-urlencoded” format per Appendix B with a character encoding of UTF-8 in the HTTP request entity-body:
REQUIRED. Value MUST be set to “client_credentials”.
OPTIONAL. The scope of the access request as described by Section 3.3.
The client MUST authenticate with the authorization server as described in Section 3.2.1.
For example, the client makes the following HTTP request using transport-layer security (with extra line breaks for display purposes only):
POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded
grant_type=client_credentials
The authorization server MUST authenticate the client.
If the access token request is valid and authorized, the authorization server issues an access token as described in Section 5.1. A refresh token SHOULD NOT be included. If the request failed client authentication or is invalid, the authorization server returns an error response as described in Section 5.2.
An example successful response:
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache
{
"access_token":"2YotnFZFEjr1zCsicMWpAA",
"token_type":"example",
"expires_in":3600,
"example_parameter":"example_value"
}
(status_code, body, headers)
A special grant endpoint for refresh_token grant_type. Refreshing an Access Token per Section 6.
The authorization server MAY issue a new refresh token
If the authorization server issued a refresh token to the client, the client makes a refresh request to the token endpoint by adding the following parameters using the “application/x-www-form-urlencoded” format per Appendix B with a character encoding of UTF-8 in the HTTP request entity-body, per Section 6:
REQUIRED. Value MUST be set to “refresh_token”.
REQUIRED. The refresh token issued to the client.
OPTIONAL. The scope of the access request as described by Section 3.3. The requested scope MUST NOT include any scope not originally granted by the resource owner, and if omitted is treated as equal to the scope originally granted by the resource owner.
For example, the client makes the following HTTP request using transport-layer security (with extra line breaks for display purposes only):
POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded
grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA
If valid and authorized, the authorization server issues an access token as described in Section 5.1. If the request failed verification or is invalid, the authorization server returns an error response as described in Section 5.2.
Get token information with refresh_token string. Developers MUST implement this method in subclass:
def authenticate_refresh_token(self, refresh_token):
token = Token.get(refresh_token=refresh_token)
if token and not token.refresh_token_revoked:
return token
refresh_token – The refresh token issued to the client
token
Authenticate the user related to this credential. Developers MUST implement this method in subclass:
def authenticate_user(self, credential):
return User.query.get(credential.user_id)
credential – Token object
user
The authorization server MAY revoke the old refresh token after issuing a new refresh token to the client. Developers MUST implement this method in subclass:
def revoke_old_credential(self, credential):
credential.revoked = True
credential.save()
credential – Token object