This part of the documentation covers the specification of OpenID Connect. Learn how to use it in Flask OpenID Connect 1.0.
authlib.oidc.core.grants.
OpenIDCodeGrant
(*args, **kwargs)¶Bases: authlib.oauth2.rfc6749.grants.authorization_code.AuthorizationCodeGrant
authlib.oidc.core.grants.
OpenIDImplicitGrant
(request, server)¶Bases: authlib.oauth2.rfc6749.grants.implicit.ImplicitGrant
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.
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.
Parameters: | grant_user – if resource owner granted the request, pass this resource owner, otherwise pass None. |
---|---|
Returns: | (status_code, body, headers) |
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.
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
authlib.oidc.core.grants.
OpenIDHybridGrant
(*args, **kwargs)¶Bases: authlib.oauth2.rfc6749.grants.authorization_code.AuthorizationCodeGrant
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.
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
Parameters: | grant_user – if resource owner granted the request, pass this resource owner, otherwise pass None. |
---|---|
Returns: | (status_code, body, headers) |
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.
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).
authlib.oidc.core.
IDToken
(payload, header, options=None, params=None)¶Bases: authlib.jose.rfc7519.claims.JWTClaims
validate
(now=None, leeway=0)¶Validate everything in claims payload.
validate_acr
()¶OPTIONAL. Authentication Context Class Reference. String specifying an Authentication Context Class Reference value that identifies the Authentication Context Class that the authentication performed satisfied. The value “0” indicates the End-User authentication did not meet the requirements of ISO/IEC 29115 level 1. Authentication using a long-lived browser cookie, for instance, is one example where the use of “level 0” is appropriate. Authentications with level 0 SHOULD NOT be used to authorize access to any resource of any monetary value. An absolute URI or an RFC 6711 registered name SHOULD be used as the acr value; registered names MUST NOT be used with a different meaning than that which is registered. Parties using this claim will need to agree upon the meanings of the values used, which may be context-specific. The acr value is a case sensitive string.
validate_amr
()¶OPTIONAL. Authentication Methods References. JSON array of strings that are identifiers for authentication methods used in the authentication. For instance, values might indicate that both password and OTP authentication methods were used. The definition of particular values to be used in the amr Claim is beyond the scope of this specification. Parties using this claim will need to agree upon the meanings of the values used, which may be context-specific. The amr value is an array of case sensitive strings.
validate_at_hash
()¶OPTIONAL. Access Token hash value. Its value is the base64url encoding of the left-most half of the hash of the octets of the ASCII representation of the access_token value, where the hash algorithm used is the hash algorithm used in the alg Header Parameter of the ID Token’s JOSE Header. For instance, if the alg is RS256, hash the access_token value with SHA-256, then take the left-most 128 bits and base64url encode them. The at_hash value is a case sensitive string.
validate_auth_time
()¶Time when the End-User authentication occurred. Its value is a JSON number representing the number of seconds from 1970-01-01T0:0:0Z as measured in UTC until the date/time. When a max_age request is made or when auth_time is requested as an Essential Claim, then this Claim is REQUIRED; otherwise, its inclusion is OPTIONAL.
validate_azp
()¶OPTIONAL. Authorized party - the party to which the ID Token was issued. If present, it MUST contain the OAuth 2.0 Client ID of this party. This Claim is only needed when the ID Token has a single audience value and that audience is different than the authorized party. It MAY be included even when the authorized party is the same as the sole audience. The azp value is a case sensitive string containing a StringOrURI value.
validate_nonce
()¶String value used to associate a Client session with an ID Token, and to mitigate replay attacks. The value is passed through unmodified from the Authentication Request to the ID Token. If present in the ID Token, Clients MUST verify that the nonce Claim Value is equal to the value of the nonce parameter sent in the Authentication Request. If present in the Authentication Request, Authorization Servers MUST include a nonce Claim in the ID Token with the Claim Value being the nonce value sent in the Authentication Request. Authorization Servers SHOULD perform no other processing on nonce values used. The nonce value is a case sensitive string.
authlib.oidc.core.
CodeIDToken
(payload, header, options=None, params=None)¶Bases: authlib.oidc.core.claims.IDToken
authlib.oidc.core.
ImplicitIDToken
(payload, header, options=None, params=None)¶Bases: authlib.oidc.core.claims.IDToken
validate_at_hash
()¶If the ID Token is issued from the Authorization Endpoint with an access_token value, which is the case for the response_type value id_token token, this is REQUIRED; it MAY NOT be used when no Access Token is issued, which is the case for the response_type value id_token.
authlib.oidc.core.
HybridIDToken
(payload, header, options=None, params=None)¶Bases: authlib.oidc.core.claims.ImplicitIDToken
validate
(now=None, leeway=0)¶Validate everything in claims payload.
validate_c_hash
()¶Code hash value. Its value is the base64url encoding of the left-most half of the hash of the octets of the ASCII representation of the code value, where the hash algorithm used is the hash algorithm used in the alg Header Parameter of the ID Token’s JOSE Header. For instance, if the alg is HS512, hash the code value with SHA-512, then take the left-most 256 bits and base64url encode them. The c_hash value is a case sensitive string. If the ID Token is issued from the Authorization Endpoint with a code, which is the case for the response_type values code id_token and code id_token token, this is REQUIRED; otherwise, its inclusion is OPTIONAL.