| - | iGov OAuth 2.0 | -January 2025 | -
| Burgin & Clancy | -Standards Track | -[Page] | -
The OAuth 2.0 protocol framework defines a mechanism to allow a - resource owner to delegate access to a protected resource for a - client - application.¶
-This specification profiles the OAuth 2.0 protocol framework to - increase baseline security, provide greater interoperability, and - structure deployments in a manner specifically applicable, but not limited to - consumer-to-government deployments.¶
-This document profiles the OAuth 2.0 web authorization framework - for - use in the context of securing web-facing application programming - interfaces (APIs), particularly Representational State Transfer - (RESTful) APIs. The OAuth 2.0 specifications accommodate a wide - range of - implementations with varying security and usability - considerations, - across different types of software clients. The OAuth - 2.0 client, - protected resource, and - authorization server profiles - defined in this document serve two - purposes:¶
-Define a mandatory baseline set of security controls suitable - for - a wide range of government use cases, while maintaining - reasonable - ease of - implementation and functionality¶
-Identify optional, advanced security controls for sensitive use - cases where increased risk justifies more stringent controls.¶
-- This OAuth profile is intended to be shared broadly, and has been - greatly influenced - by the - HEART OAuth2 Profile [HEART.OAuth2].¶
-- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", - and - "OPTIONAL" in this document are to be interpreted as described - in - RFC 2119 [RFC2119] - .¶
-- All uses of - JSON Web Signature (JWS) [RFC7515] - and - JSON Web Encryption (JWE) [RFC7516] - data - structures in this specification utilize the JWS Compact - Serialization - or the JWE Compact Serialization; the JWS JSON - Serialization and the - JWE JSON Serialization are not used.¶
-- This specification uses the terms "Access Token", "Authorization - Code", "Authorization Endpoint", "Authorization Grant", - "Authorization - Server", "Client", "Client Authentication", "Client - Identifier", - "Client Secret", "Grant Type", "Protected Resource", - "Redirection - URI", "Refresh Token", "Resource Owner", "Resource - Server", "Response - Type", and "Token Endpoint" defined by - OAuth - 2.0 [RFC6749] - , the terms "Claim Name", "Claim Value", and "JSON Web Token - (JWT)" - defined by - JSON Web Token (JWT) [RFC7519] - , - and the terms defined by - OpenID Connect - Core 1.0 [OpenID.Core] - .¶
-This specification defines requirements for the following - components:¶
-OAuth 2.0 clients.¶
-OAuth 2.0 authorization servers.¶
-OAuth 2.0 protected resources.¶
-The specification also defines features for interaction between - these components:¶
- -When an iGov-compliant component is interacting with other - iGov-compliant components, in any valid combination, all components - MUST fully conform to the features and requirements of this - specification. All interaction with non-iGov components is outside - the scope of this specification.¶
-An iGov-compliant OAuth 2.0 authorization server MUST support all - features as described in this specification. A general-purpose - authorization server MAY support additional features for use with - non-iGov clients and protected resources.¶
-An iGov-compliant OAuth 2.0 client MUST use all functions as - described in this specification. A general-purpose client library - MAY - support additional features for use with non-iGov authorization - servers and protected resources.¶
-An iGov-compliant OAuth 2.0 protected resource MUST use all - functions as described in this specification. A general-purpose - protected resource library MAY support additional features for use - with non-iGov authorization servers and clients.¶
-All network connections MUST be made using TLS 1.3 or above. - Each originator of a TLS connection MUST verify the destination's certificate. - Additionally, the following four TLS 1.2 cipher suites MAY be used:¶
-TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256¶
-TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384¶
-TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256¶
-TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384¶
-Implementers of this profile SHOULD monitor the progress of specifications of post-quantum - cryptography for TLS implementations. - Implementers MAY adopt a cipher suite not included in BCP195 [BCP195] when post quantum safety - is required if the cipher suite is supported in the implementation environment.¶
-An example of an emerging PQ cipher suite that is broadly supported at the time of writing is X25519MLKEM768, specified by - Post-quantum Hybrid Key Exchange with ML-KEM in the Internet Key Exchange Protocol Version 2 (IKEv2) [mlkem.ikev2].¶
-- For the authorization_endpoint, the authorization server MAY allow - additional cipher suites that are permitted by the latest version of BCP195 [BCP195], - if necessary to allow sufficient interoperability with users' web browsers or as required by local regulations.¶
-- NOTE: Permitted cipher suites are those listed in BCP195 [BCP195] that do not explicitly say MUST NOT use.¶
-Endpoints for use by web browsers MUST use mechanisms to ensure that connections cannot be downgraded - using TLS Stripping attacks. Protected resources MAY implement an HTTP Strict Transport Security policy as defined in - HTTP Strict Transport Security (HSTS) [RFC6797] to mitigate these attacks. Protected resources SHOULD - consider registering web domain names with browsers that offer browser-side ("preload") HSTS policy enforcement to further mitigate - TLS downgrade attacks.¶
-- The following profile descriptions give patterns of deployment - for - use in different types of client applications based on the OAuth - grant type. - Additional grant types, such as assertions, - chained tokens, or other - mechanisms, are out of scope of this - profile and must be covered - separately by appropriate profile - documents.¶
-This client type applies to clients that act on behalf of a - particular resource owner and require delegation of that - user's authority to access the protected resource. - Furthermore, these clients are capable of interacting with a - separate web browser application to facilitate the resource - owner's interaction with the authentication endpoint of the - authorization server.¶
-These clients MUST use the authorization code flow of OAuth 2.0 - by sending the resource owner to the authorization endpoint to - obtain authorization. The user MUST authenticate to the - authorization endpoint using either private_key_jwt or - mTLS [RFC8705] authentication. - - The user's web browser is then redirected back to a URI hosted by the client - service, from which the client can obtain an authorization code passed as - a query parameter. The client then presents that authorization code along - with its own credentials (private_key_jwt or mTLS) to the authorization - server's token endpoint to obtain an access token. - A non-person entity PKI SHOULD be used rather than a self-signed TLS client certificate if available. - The PKI method provides security value by - allowing the authorization server to rely upon externally validated client entity - identifiers and attributes, and simplifies lifecycle management, including key rotation.¶
-- These clients MUST be associated with a unique public key, as - described in - Section 2.4 - .¶
-This client type MAY request and be issued a refresh token if - the security parameters of the access request allow for it.¶
-This client type applies to clients that act on behalf of a - particular resource owner, such as an app on a mobile platform, - and require delegation of that user's - authority to access the - protected resource. Furthermore, these - clients are capable of - interacting with a separate web browser - application to facilitate - the resource owner's interaction with - the authentication endpoint - of the authorization server. In - particular, this client type runs - natively on the resource - owner's - device, often leading to many - identical instances of a piece of - software operating in different - environments and running - simultaneously for different end users.¶
-These clients MUST use the authorization code flow of OAuth 2.0 - by sending the resource owner to the authorization endpoint to - obtain authorization. The user MUST authenticate to the - authorization endpoint. The user is then - redirected back to a URI hosted by the client, from which the - client can obtain an authorization code passed as a query - parameter. The client then presents that authorization code along - to the authorization server's token endpoint to obtain an access - token.¶
-Native clients MUST either:¶
-use dynamic client registration to obtain a separate client - id for each instance, or¶
-- act as a public client by using a common client id and use - PKCE [RFC7636] to protect calls to the - token endpoint.¶
-Native applications using dynamic registration SHOULD generate - a unique public and private key pair on the device and register - that public key value with the authorization server, or - obtain a certificate from a trusted Certificate Authority.¶
-Public Clients do not authenticate with the Token Endpoint.¶
-This client type MUST NOT request or be issued a refresh - token.¶
-This profile applies to clients that connect directly to - protected resources and do not act on behalf of a particular - resource owner, such as those clients that facilitate bulk - transfers.¶
-These clients use the client credentials flow of OAuth 2.0 by - sending a request to the token endpoint with the client's - credentials and obtaining an access token in the response. Since - this profile does not involve an authenticated user, this flow is - appropriate only for trusted applications, such as those that - would traditionally use a developer key. For example, a partner - system that performs bulk data transfers between two systems - would be considered a direct access client.¶
-While a bearer token can be used by anyone in possession of the token, a sender-constrained token is - bound to a particular symmetric or asymmetric key issued to, or already possessed by, the client. - The association of the key to the token is also communicated to the protected resource. When the client - presents the token to the protected resource, it is also required to demonstrate possession of the corresponding key.¶
-As described in OAuth 2.0 Security Best Common Practices [SecBCP], sender-constrained tokens could - prevent a number of attacks on OAuth that entail the misuse of stolen and leaked access tokens by unauthorized parties. - The attacker would need to obtain the legitimate client's cryptographic key along with the access - token to gain access to protected resources.¶
-All clients MUST use proof of possession to sender-constrain access tokens using either mTLS [RFC8705] or - DPoP [RFC9449].¶
-OAuth 2.0 clients and Authorization Servers MUST support the mechanism specified in OAuth 2.0 Step Up Authentication Challenge - Protocol" [RFC9470] to communicate authentication context and implement interoperable step up authentication.¶
-Protected resources MAY use authentication context or step up authentication to implement access controls.¶
-This profile acknowledges government use cases will likely operate within an ecosystem of authentication methods of highly variable security - value for the foreseeable future by imposing requirements to enable protected resources with basic capabilities to communicate - requirements for authentication strength and recency to supporting authorization clients and servers, as well as the capability to enforce access - policies using access tokens augmented with the strength and recency of the authentication event that led to the issuance of each specific access token.¶
-This profile will leverage the supporting server metadata, request, token claims and values, and error messages from OAuth 2.0 Step Up Authentication Challenge - Protocol" [RFC9470] and OpenID Connect Core 1.0 [OpenID.Core].¶
-Digital identity policies and semantic mappings to string values are required for implementation but are out of scope for this technical profile.¶
-OAuth 2.0 MUST NOT be used as an authentication protocol. Use of the iGov OpenID Connect Profile" [OpenID.iGov] is RECOMMENDED to provide the identity - authentication layer for iGov OAuth 2.0 delegated access use cases.¶
-All clients MUST register with the authorization server. For - client software that may be installed on multiple client - instances, - such as native applications or web application software, - each client instance MAY receive a unique client identifier from - the authorization server. Clients that share client identifiers are - considered public clients.¶
-Client registration MAY be completed by either static configuration - (out-of-band, through an administrator, etc...) or dynamically.¶
-If a client uses mTLS [RFC8705] for client authentication or to sender-constrain tokens, the client MUST include the tls_client_certificate_bound_access_tokens parameter in its registration metadata.¶
-If a client uses DPoP [RFC9449] to sender constrain tokens, the client MUST include the dpop_bound_access_tokens parameter in its registration metadata.¶
-Clients using mTLS for client authentication or to sender-constrain tokens MUST register their TLS certificate's subject DN with the authorization server. - Clients using self-signed certificate option are not guaranteed uniqueness of their certificate fingerprint.¶
-Clients using the authorization code grant type - MUST register - their full redirect URIs. The Authorization Server - MUST validate - the redirect URI given by the client at the - authorization endpoint - using strict string comparison.¶
-A client MUST protect the values passed back to its redirect - URI by ensuring that the redirect URI is one of the following:¶
-Hosted on a website with Transport Layer Security (TLS) - protection (a Hypertext Transfer Protocol - Secure - (HTTPS) URI)¶
-Hosted on a client-specific non-remote-protocol URI scheme - (e.g., myapp://)¶
-Hosted on the local domain of the client (e.g., - http://localhost/)¶
-Clients SHOULD NOT have multiple redirect URIs on different domains.¶
-Clients MUST use a unique redirect URI for each logical authorization server.¶
-Clients MUST NOT forward values passed back to their redirect - URIs to other arbitrary or user-provided URIs (a practice known - as - an "open redirector").¶
-All clients MUST use the PKCE S256 code challenge method as described in - Proof Key for Code Exchange by OAuth Public Clients [RFC7636] and - include the "code_challenge" parameter - and "code_challenge_method", set to "S256", in the authorization request. - The PKCE code_verifier value MUST contain at least 128 bits of entropy.¶
-
- Full clients and browser-embedded clients making a request to the
- authorization endpoint MUST use an unpredictable value for the
- state
- parameter with at least 128 bits of entropy. Clients MUST
- validate
- the value of the
- state
- parameter upon
- return to the redirect URI and MUST ensure that the
- state value is
- securely tied to the user's current session
- (e.g., by
- relating
- the state value to a session identifier issued by
- the client
- software to the browser).¶
Clients MUST include their full redirect URI in the - authorization request. To prevent open redirection and other - injection attacks, the authorization server MUST match the entire - redirect URI using a direct string comparison against registered - values and MUST reject requests with an invalid or missing redirect - URI.¶
-The following is a sample response from a web-based client to - the - end user's browser for the purpose of redirecting the end - user - to the authorization server's authorization endpoint:¶
--NOTE: '\' line wrapping per RFC 8792 - -HTTP/1.2 302 Found -Cache-Control: no-cache -Connection: close -Content-Type: text/plain; charset=UTF-8 -Date: Wed, 07 Jan 2015 20:24:15 GMT -Location: \ - https://idp-p.example.com/authorize?client_id=55f9f559-2496-49d4-b\ -6c3-351a586b7484&nonce=cd567ed4d958042f721a7cdca557c30d&response_typ\ -e=code&scope=openid+email&redirect_uri=https%3A%2F%2Fclient.example.\ -org%2Fcb -Status: 302 Found -¶ -
This causes the browser to send the following (non-normative) request to the - authorization endpoint (inline wraps for display purposes only):¶
--NOTE: '\' line wrapping per RFC 8792 - -GET /authorize? - client_id=55f9f559-2496-49d4-b6c3-351a586b7484 - &nonce=cd567ed4d958042f721a7cdca557c30d - &response_type=code - &scope=openid+email - &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb HTTP/1.1 -Host: idp-p.example.com -¶ -
- Full clients, native clients with dynamically registered keys, - and direct access clients as defined above MUST - authenticate to the authorization server's token endpoint using either - the private_key_jwt method as defined in - OpenID Connect Core [OpenID.Core] - or - the mutually-authenticated transport layer security (MTLS) request method - defined in - OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens [RFC8705]. - If using the private_key_jwt method, the request MUST be a JWT assertion as defined by the - JWT Profile for OAuth 2.0 Client Authentication and Authorization Grants [RFC7523]. - If using the mTLS method, the request must be made over a mutually authenticated TLS channel. - - For both methods, the request MUST include the following claims:¶
-The client MAY specify a strength of authentication and maximum age to the authorization server that should be met - when issuing an access token for the requesting client by including the following claims:¶
-Furthermore, if the authorization request is a follow-up to a prior request that did not meet the client's initial or subsequent authentication - strength or recency requirements, the client should include the insuffient_user_authentication error code, along with acr_values or max_age - values that specify expected strength and recency requirements to be provided to the authentication provider, such as the OpenID Provider, in a new - authentication request.¶
-Additionally, if the client uses mTLS [RFC8705] for client authentication or to sender-constrain - tokens, the client MUST include the following claim in the client assertion.¶
-The following sample claim set illustrates the use of the - required - claims for a client authentication JWT as defined in this - profile using the private_key_jwt authentication method; - additional claims MAY be included in the claim set.¶
-{
- "iss": "55f9f559-2496-49d4-b6c3-351a586b7484",
- "sub": "55f9f559-2496-49d4-b6c3-351a586b7484",
- "aud": "https://idp-p.example.com/token",
- "iat": 1418698788,
- "exp": 1418698848,
- "jti": "1418698788/107c4da5194df463e52b56865c5af34e5595"
- "cnf":{
- "x5t#S256":"A4DtL2JmUMhAsvJj5tKyn64SqzmuXbMrJa0n761y5v0"
- }
- }
-¶
-- The JWT assertion MUST be signed by the client using the client's - private key. See - Section 2.4 - for mechanisms - by which the client can make its public key known to - the server. The - authorization server MUST support the RS256 - signature method (the - Rivest, Shamir, and Adleman (RSA) signature - algorithm with a - 256-bit - hash) and MAY use other asymmetric - signature methods listed in the - JSON Web Algorithms (JWA [RFC7518]) ) - specification.¶
-The following sample JWT contains the above claims and has been - signed using the RS256 JWS algorithm and the client's own private - key (with line breaks for display purposes only):¶
--NOTE: '\' line wrapping per RFC 8792 - -eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiJ9.ew0KICAgImlzcyI6ICI1NWY5ZjU1OS0\ -yNDk2LTQ5ZDQtYjZjMy0zNTFhNTg2Yjc0ODQiLA0KICAgInN1YiI6ICI1NWY5ZjU1OS0\ -yNDk2LTQ5ZDQtYjZjMy0zNTFhNTg2Yjc0ODQiLA0KICAgImF1ZCI6ICJodHRwczovL2l\ -kcC1wLmV4YW1wbGUuY29tL3Rva2VuIiwNCiAgICJpYXQiOiAxNDE4Njk4Nzg4LA0KICA\ -gImV4cCI6IDE0MTg2OTg4NDgsDQogICAianRpIjogIjE0MTg2OTg3ODgvMTA3YzRkYTU\ -xOTRkZjQ2M2U1MmI1Njg2NWM1YWYzNGU1NTk1Ig0KfQ.t-_gX8JQGq3G2OEc2kUCQ8zV\ -j7pqff87Sua5nktLIHj28l5onO5VpsL4sRHIGOvrpo7XO6jgtPWy3iLXv3-NLyo1TWHb\ -tErQEGpmf7nKiNxVCXlGYJXSDJB6shP3OfvdUc24urPJNUGBEDptIgT7-Lhf6BbwQNlM\ -QubNeOPRFDqQoLWqe7UxuI06dKX3SEQRMqcxYSIAfP7CQZ4WLuKXb6oEbaqz6gL4l6p8\ -3G7wKGDeLETOTHszt-ZjKR38v4F_MnSrx8e0iIqgZwurW0RtetEWvynOCJXk-p166T7q\ -ZR45xuCxgOotXY6O3et4n77GtgspMgOEKj3b_WpCiuNEwQ -¶ -
This is sent in the request to the token endpoint as in the - following example:¶
-POST /token HTTP/1.1 -NOTE: '\' line wrapping per RFC 8792 - -Content-Type: application/x-www-form-urlencoded -User-Agent: Rack::OAuth2 (1.0.8.7) (2.5.3.2, ruby 2.1.3 (2014-09-19)) -Accept: */* -Date: Tue, 16 Dec 2014 02:59:48 GMT -Content-Length: 884 -Host: idp-p.example.com - -grant_type=authorization_code -&code=sedaFh -&scope=openid+email -&client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertio\ -n-type%3Ajwt-bearer -&client_assertion=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiJ9.ew0KICAgImlzc\ -yI6ICI1NWY5ZjU1OS0yNDk2LTQ5ZDQtYjZjMy0zNTFhNTg2Yjc0ODQiLA0KICAgInN1Y\ -iI6ICI1NWY5ZjU1OS0yNDk2LTQ5ZDQtYjZjMy0zNTFhNTg2Yjc0ODQiLA0KICAgImF1Z\ -CI6ICJodHRwczovL2lkcC1wLmV4YW1wbGUuY29tL3Rva2VuIiwNCiAgICJpYXQiOiAxN\ -DE4Njk4Nzg4LA0KICAgImV4cCI6IDE0MTg2OTg4NDgsDQogICAianRpIjogIjE0MTg2O\ -Tg3ODgvMTA3YzRkYTUxOTRkZjQ2M2U1MmI1Njg2NWM1YWYzNGU1NTk1Ig0KfQ.t-_gX8\ -JQGq3G2OEc2kUCQ8zVj7pqff87Sua5nktLIHj28l5onO5VpsL4sRHIGOvrpo7XO6jgtP\ -Wy3iLXv3-NLyo1TWHbtErQEGpmf7nKiNxVCXlGYJXSDJB6shP3OfvdUc24urPJNUGBED\ -ptIgT7-Lhf6BbwQNlMQubNeOPRFDqQoLWqe7UxuI06dKX3SEQRMqcxYSIAfP7CQZ4WLu\ -KXb6oEbaqz6gL4l6p83G7wKGDeLETOTHszt-ZjKR38v4F_MnSrx8e0iIqgZwurW0Rtet\ -EWvynOCJXk-p166T7qZR45xuCxgOotXY6O3et4n77GtgspMgOEKj3b_WpCiuNEwQ -¶ -
- Clients using the authorization code grant type or direct
- access
- clients using the client credentials grant type MUST have a
- public
- and private key pair for use in authentication to the token
- endpoint. These clients MUST register their public keys in their
- client registration metadata by either sending the public key
- directly in the
- jwks
- field or by
- registering a
- jwks_uri
- that MUST be
- reachable by the authorization server. It is
- RECOMMENDED that
- clients use a
- jwks_uri
- if possible as
- this allows for key rotation more easily. This applies to both
- dynamic and static (out-of-band) client registration.¶
- The
- jwks
- field or the content
- available from the
- jwks_uri
- of a client
- MUST contain a public key in
- JSON Web Key Set
- (JWK Set) [RFC7517]
- format. The authorization server MUST validate the
- content of the
- client's registered jwks_uri document and verify that
- it contains a
- JWK Set. The following example is of a 2048-bit RSA
- key:¶
-NOTE: '\' line wrapping per RFC 8792
-
-{
- "keys": [
- {
- "alg": "RS256",
- "e": "AQAB",
- "n": "kAMYD62n_f2rUcR4awJX4uccDt0zcXRssq_mDch5-ifcShx9aTtTVza2\
-3PTn3KaKrsBXwWcfioXR6zQn5eYdZQVGNBfOR4rxF5i7t3hfb4WkS50EK1gBYk2lO9NS\
-rQ-xG9QsUsAnN6RHksXqsdOqv-nxjLexDfIJlgbcCN9h6TB-C66ZXv7PVhl19gIYVifS\
-U7liHkLe0l0fw7jUI6rHLHf4d96_neR1HrNIK_xssr99Xpv1EM_ubxpktX0T925-qej9\
-fMEpzzQ5HLmcNt1H2_VQ_Ww1JOLn9vRn-H48FDj7TxlIT74XdTZgTv31w_GRPAOfyxEw\
-_ZUmxhz5Z-gTlQ",
- "kty": "RSA",
- "kid": "oauth-client"
- }
- ]
-}
-¶
-For reference, the corresponding public/private key pair for - this - public key is the following (in JWK format):¶
-
-NOTE: '\' line wrapping per RFC 8792
-
-{
- "alg": "RS256",
- "d": "PjIX4i2NsBQuOVIw74ZDjqthYsoFvaoah9GP-cPrai5s5VUIlLoadEAdGbBr\
-ss_6dR58x_pRlPHWh04vLQsFBuwQNc9SN3O6TAaai9Jg5TlCi6V0d4O6lUoTYpMR0cxF\
-IU-xFMwII--_OZRgmAxiYiAXQj7TKMKvgSvVO7-9-YdhMwHoD-UrJkfnZckMKSs0BoAb\
-jReTski3IV9f1wVJ53_pmr9NBpiZeHYmmG_1QDSbBuY35Zummut4QShF-fey2gSALdp9\
-h9hRk1p1fsTZtH2lwpvmOcjwDkSDv-zO-4Pt8NuOyqNVPFahROBPlsMVxc_zjPck8ltb\
-lalBHPo6AQ",
- "e": "AQAB",
- "n": "kAMYD62n_f2rUcR4awJX4uccDt0zcXRssq_mDch5-ifcShx9aTtTVza23PTn\
-3KaKrsBXwWcfioXR6zQn5eYdZQVGNBfOR4rxF5i7t3hfb4WkS50EK1gBYk2lO9NSrQ-x\
-G9QsUsAnN6RHksXqsdOqv-nxjLexDfIJlgbcCN9h6TB-C66ZXv7PVhl19gIYVifSU7li\
-HkLe0l0fw7jUI6rHLHf4d96_neR1HrNIK_xssr99Xpv1EM_ubxpktX0T925-qej9fMEp\
-zzQ5HLmcNt1H2_VQ_Ww1JOLn9vRn-H48FDj7TxlIT74XdTZgTv31w_GRPAOfyxEw_ZUm\
-xhz5Z-gTlQ",
- "kty": "RSA",
- "kid": "oauth-client"
-}
-¶
-Note that the second example contains both the public and - private - keys, while the first example contains the public key only.¶
-- - Clients MUST use the authorization request header field mechanism to send bearer tokens as defined by - [RFC6750].¶
-An example of an OAuth-protected call to the OpenID Connect - UserInfo endpoint, sending the token in the Authorization header, - follows:¶
--NOTE: '\' line wrapping per RFC 8792 - -GET /userinfo HTTP/1.1 -Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.eyJleHAiOjE0MTg3MDI0MTIsI\ -\mF1ZCI6WyJjMWJjODRlNC00N2VlLTRiNjQtYmI1Mi01Y2RhNmM4MWY3ODgiXSwiaXNz\ -IjoiaHR0cHM6XC9cL2lkcC1wLmV4YW1wbGUuY29tXC8iLCJqdGkiOiJkM2Y3YjQ4Zi1i\ -YzgxLTQwZWMtYTE0MC05NzRhZjc0YzRkZTMiLCJpYXQiOjE0MTg2OTg4MTJ9.iHMz_tz\ -Z90_b0QZS-AXtQtvclZ7M4uDAs1WxCFxpgBfBanolW37X8h1ECrUJexbXMD6rrj_uuWE\ -qPD738oWRo0rOnoKJAgbF1GhXPAYnN5pZRygWSD1a6RcmN85SxUig0H0e7drmdmRkPQg\ -bl2wMhu-6h2Oqize4dKmykN9UX_2drXrooSxpRZqFVYX8PkCvCCBuFy2O-HPRov_SwtJ\ -Mk5qjUWMyn2I4Nu2s-R20aCA-7T5dunr0iWCkLQnVnaXMfA22RlRiU87nl21zappYb1_\ -EHF9ePyq3Q353cDUY7vje8m2kKXYTgc_bUAYuW-W3SMSw5UlKa -¶ -
- All servers MUST conform to applicable recommendations found in the - Security Considerations sections of - [RFC6749] - and those - found in the - OAuth Threat Model - Document [RFC6819].¶
-The authorization server MUST protect all communications to and - from - its OAuth endpoints using TLS.¶
-
- The authorization server MUST support the
- authorization_code, and MAY support the
- client_credentials
- grant types as described in
- Section 2. The
- authorization server MUST limit each registered client
- (identified
- by a client ID) to a single grant type only, since a
- single piece of
- software will be functioning at runtime in only one
- of the modes
- described in
- Section 2. Clients that have
- multiple modes of operation MUST have a
- separate client ID for each
- mode.¶
The authorization server MUST enforce client authentication as - described above for the authorization code and client credentials - grant types. Public client cannot authenticate to the authorization server.¶
-The authorization server MUST validate all redirect - URIs for authorization code grant types.¶
-The authorization server MUST confirm thumbprints of client keys - if mTLS is used for client authentication or sender-constraining tokens.¶
-- Dynamic Registration allows for authorized Clients to on-board programmatically without administrative intervention. This is particularly important in ecosystems with many potential Clients, including Mobile Apps acting as independent Clients. Authorization servers MUST support dynamic client registration, - and clients MAY register using the - Dynamic - Client Registration Protocol [RFC7591] - for authorization code grant types. Clients MUST NOT - dynamically - register for the - client credentials grant type. - Authorization - servers MAY limit the - scopes available to dynamically - registered - clients.¶
-Authorization - - servers MAY protect their Dynamic Registration endpoints by requiring clients to present credentials that the authorization server would recognize as authorized participants. Authorization servers MAY accept signed software statements as described in [RFC7591] - issued to client software developers from a - trusted registration - entity. The software statement can be used to - tie together many - instances of the same client software that will be - run, dynamically - registered, and authorized separately at runtime. - The software - statement MUST include the following client metadata - parameters:¶
-- A client using the tls_client_auth authentication method MUST use exactly one of the below metadata parameters to indicate the certificate - subject value that the authorization server is to expect when authenticating the respective client:¶
-When prompting the end user with an interactive approval page, - the authorization server MUST indicate to the user:¶
-Whether the client was dynamically registered, or else - statically registered by a trusted administrator, or a public client.¶
-Whether the client is associated with a software statement, - and in which case provide information about the trusted issuer - of the software statement.¶
-What kind of access the client is requesting, including - scope, protected resources (if applicable beyond scopes), - and access duration.¶
-For example, for - native clients a message indicating a new App installation has been - registered as a client can help users determine if this is the expected - behaviour. This signal helps users protect themselves from potentially - rogue clients.¶
-The authorization server MUST support and verify sender-constraining tokens using mTLS [RFC8705] and DPoP [RFC9449].¶
-The Authorization Server MUST NOT issue the client an access token if the client included the
- tls_client_certificate_bound_access_tokens
- parameter in its registration metadata and makes a request to the token endpoint over a non-mutual-TLS connection.¶
- The authorization server MUST provide an - OpenID Connect service discovery [OpenID.Discovery] - endpoint listing the components relevant to the OAuth 2.0 protocol:¶
-If the TLS method for client authentication is used, exactly one authentication method metadata value MUST be included.¶
-If the authorization server is also an OpenID Connect Provider, - it MUST provide a discovery endpoint meeting the requirements - listed - in Section 3.6 of the iGov OpenID Connect profile.¶
-The following example shows the JSON document found at a - discovery endpoint for an authorization server:¶
-{
- "request_parameter_supported": true,
- "registration_endpoint": "https://idp-p.example.com/register",
- "userinfo_signing_alg_values_supported": [
- "HS256", "HS384", "HS512", "RS256", "RS384", "RS512"
- ],
- "token_endpoint": "https://idp-p.example.com/token",
- "request_uri_parameter_supported": false,
- "request_object_encryption_enc_values_supported": [
- "A192CBC-HS384", "A192GCM", "A256CBC+HS512",
- "A128CBC+HS256", "A256CBC-HS512",
- "A128CBC-HS256", "A128GCM", "A256GCM"
- ],
- "token_endpoint_auth_methods_supported": [
- "private_key_jwt",
- ],
- "jwks_uri": "https://idp-p.example.com/jwk",
- "authorization_endpoint": "https://idp-p.example.com/authorize",
- "require_request_uri_registration": false,
- "introspection_endpoint": "https://idp-p.example.com/introspect",
- "request_object_encryption_alg_values_supported": [
- "RSA-OAEP", ?RSA1_5", "RSA-OAEP-256"
- ],
- "service_documentation": "https://idp-p.example.com/about",
- "response_types_supported": [
- "code", "token"
- ],
- "token_endpoint_auth_signing_alg_values_supported": [
- "HS256", "HS384", "HS512", "RS256", "RS384", "RS512"
- ],
- "revocation_endpoint": "https://idp-p.example.com/revoke",
- "request_object_signing_alg_values_supported": [
- "HS256", "HS384", "HS512", "RS256", "RS384", "RS512"
- ],
- "grant_types_supported": [
- "authorization_code",
- "client_credentials"
- ],
- "scopes_supported": [
- "profile", "openid", "email", "address", "phone", "offline_access"
- ],
- "op_tos_uri": "https://idp-p.example.com/about",
- "issuer": "https://idp-p.example.com/",
- "op_policy_uri": "https://idp-p.example.com/about"
- "tls_client_certificate_bound_access_tokens": "true"
- "dpop_signing_alg_values_supported": ["PS256", "ES256"]
-}
-¶
-Clients and protected resources SHOULD cache this discovery - information. It is RECOMMENDED that servers provide cache - information through HTTP headers and make the cache valid for at - least one week.¶
-The server MUST provide its public key in JWK Set format. The - key - MUST contain the following fields:¶
-The following is an example of a 2048-bit RSA public key:¶
-{
-NOTE: '\' line wrapping per RFC 8792
-
-"keys": [
- {
- "alg": "RS256",
- "e": "AQAB",
- "n": "o80vbR0ZfMhjZWfqwPUGNkcIeUcweFyzB2S2T-hje83IOVct8gVg9FxvHP\
-K1ReEW3-p7-A8GNcLAuFP_8jPhiL6LyJC3F10aV9KPQFF-w6Eq6VtpEgYSfzvFegNiPt\
-pMWd7C43EDwjQ-GrXMVCLrBYxZC-P1ShyxVBOzeR_5MTC0JGiDTecr_2YT6o_3aE2SIJ\
-u4iNPgGh9MnyxdBo0Uf0TmrqEIabquXA1-V8iUihwfI8qjf3EujkYi7gXXelIo4_gipQ\
-YNjr4DBNlE0__RI0kDU-27mb6esswnP2WgHZQPsk779fTcNDBIcYgyLujlcUATEqfCaP\
-DNp00J6AbY6w",
- "kty": "RSA",
- "kid": "rsa1"
- }
- ]
-}
-¶
-Clients and protected resources SHOULD cache this key. It is - RECOMMENDED that servers provide cache information through HTTP - headers and make the cache valid for at least one week.¶
-Token revocation allows a client to signal to an authorization - server that a given token will no longer be used.¶
-An authorization server MUST revoke the token if the client - requesting the revocation is the client to which the token was - issued, the client has permission to revoke tokens, and the token - is - revocable.¶
-A client MUST immediately discard the token and not use it again - after revoking it.¶
-The authorization server MUST require use of PKCE - (Proof Key for Code Exchange by OAuth Public Clients [RFC7636]) by all clients, - rejecting requests to the authorization endpoint from clients that do not contain a code challenge. - Authorization servers MUST support the S256 code challenge method. - Authorization servers MUST NOT allow a client to use the plain - code challenge - method.¶
-The authorization server MUST compare a client's registered - redirect URIs with the redirect URI presented during an - authorization request using an exact string match.¶
-Authorization Servers MAY issue refresh tokens to clients under the - following context:¶
-Clients MUST be registered with the Authorization Server.¶
-Clients MUST present a valid client_id. Confidential clients MUST present a signed client_assertion with their associated keypair.¶
-Clients using the Direct Credentials method MUST NOT be issued refresh_tokens. - These clients MUST present their client credentials with a new access_token request - and the desired scope.¶
-Unlike the core OAuth protocol, the iGov profile intends to allow - compliant protected resources to connect to compliant authorization - servers.¶
-All iGov-compliant authorization servers issue - cryptographically signed sender-constrained tokens in the JSON Web Token (JWT) - format. - The information carried in the JWT is intended to allow a - protected - resource to quickly test the integrity of the token - without - additional network calls, and to allow the protected - resource to - determine which authorization server issued the token. - The protected resource MAY use the authorization server token introspection service - to retrieve additional security information about the token.¶
-The server MUST issue tokens as JWTs with, at minimum, the - following claims:¶
-Additionally, if the client uses mTLS [RFC8705] for client authentication or to sender-constrain tokens, the server MUST include the following claim in the access token.¶
-The following sample claim set illustrates the use of the - required claims for an access token as defined in this profile; - additional claims MAY be included in the claim set:¶
-{
- "exp": 1418702388,
- "azp": "55f9f559-2496-49d4-b6c3-351a586b7484",
- "iss": "https://idp-p.example.com/",
- "jti": "2402f87c-b6ce-45c4-95b0-7a3f2904997f",
- "iat": 1418698788,
- "acr": "myACR",
- "auth_time": 16463400198,
- "cnf": {
- "x5t#S256":"A4DtL2JmUMhAsvJj5tKyn64SqzmuXbMrJa0n761y5v0"
- }
-}
-¶
-- - The access tokens MUST be signed with - JWS [RFC7515] - . If private_key_jwt is used, the authorization server MUST support - the RS256 signature method - for tokens and MAY use other asymmetric - signing methods as defined - in the - IANA - JSON Web Signatures and Encryption - Algorithms registry [JWS.JWE.Algs] - . The - JWS header MUST contain the following fields:¶
-This example access token has been signed with the server's - private key using RS256:¶
--NOTE: '\' line wrapping per RFC 8792 - -eyJhbGciOiJSUzI1NiJ9.ew0KICAgImV4cCI6IDE0MTg3MDIzODgsDQogICAiYXpwIjo\ -gIjU1ZjlmNTU5LTI0OTYtNDlkNC1iNmMzLTM1MWE1ODZiNzQ4NCIsDQogICAiaXNzIjo\ -gImh0dHBzOi8vaWRwLXAuZXhhbXBsZS5jb20vIiwNCiAgICJqdGkiOiAiMjQwMmY4N2M\ -tYjZjZS00NWM0LTk1YjAtN2EzZjI5MDQ5OTdmIiwNCiAgICJpYXQiOiAxNDE4Njk4Nzg\ -4LA0KICAgImtpZCI6ICJyc2ExIg0KfQ.iB6Ix8Xeg-L-nMStgE1X75w7zgXabzw7znWU\ -ECOsXpHfnYYqb-CET9Ah5IQyXIDZ20qEyN98UydgsTpiO1YJDDcZV4f4DgY0ZdG3yBW3\ -XqwUQwbgF7Gwza9Z4AdhjHjzQx-lChXAyfL1xz0SBDkVbJdDjtXbvaSIyfF7ueWF3M1C\ -M70-GXuRY4iucKbuytz9e7eW4Egkk4Aagl3iTk9-l5V-tvL6dYu8IlR93GKsaKE8bng0\ -EZ04xcnq8s4V5Yykuc_NARBJENiKTJM8w3wh7xWP2gvMp39Y0XnuCOLyIx-J1ttX83xm\ -pXDaLyyY-4HT9XHT9V73fKF8rLWJu9grrA -¶ -
- Refresh tokens SHOULD be signed with - JWS [RFC7515] - using the same private key and contain - the same set of claims as - the - access tokens.¶
-- The authorization server MAY encrypt access tokens and refresh - tokens using - JWE [RFC7516] - . Encrypted access - tokens MUST be encrypted using the public key of - the protected - resource. Encrypted refresh tokens MUST be encrypted - using the - authorization server's public key.¶
-Token introspection allows a protected resource to query the - authorization server for metadata about a token. The protected - resource makes a request over a mutually authenticated TLS connection like the following to the token - introspection endpoint:¶
--NOTE: '\' line wrapping per RFC 8792 - -POST /introspect HTTP/1.1 -User-Agent: Faraday v0.9.0 -Content-Type: application/x-www-form-urlencoded -Accept-Encoding: gzip;q=1.0,deflate;q=0.6,identity;q=0.3 -Accept: */* -Connection: close -Host: as-va.example.com -Content-Length: 1412 - -client_assertion=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiJ9.eyJpc3MiOiJhMm\ -MzNjkxOS0wMWZmLTQ4MTAtYTgyOS00MDBmYWQzNTczNTEiLCJzdWIiOiJhMmMzNjkxOS\ -0wMWZmLTQ4MTAtYTgyOS00MDBmYWQzNTczNTEiLCJhdWQiOiJodHRwczovL2FzLXZhLm\ -V4YW1wbGUuY29tL3Rva2VuIiwiaWF0IjoxNDE4Njk4ODE0LCJleHAiOjE0MTg2OTg4Nz\ -QsImp0aSI6IjE0MTg2OTg4MTQvZmNmNDQ2OGY2MDVjNjE1NjliOWYyNGY5ODJlMTZhZW\ -Y2OTU4In0.md7mFdNBaGhiJfE_pFkAAWA5S-JBvDw9Dk7pOOJEWcL08JGgDFoi9UDbg3\ -sHeA5DrrCYGC_zw7fCGc9ovpfMB7W6YN53hGU19LtzzFN3tv9FNRq4KIzhK15pns9jck\ -Ktui3HZ25L_B-BnxHe7xNo3kA1M-p51uYYIM0hw1SRi2pfwBKG5O8WntybLjuJ0R3X97\ -zvqHn2Q7xdVyKlInyNPA8gIZK0HVssXxHOI6yRrAqvdMn_sneDTWPrqVpaR_c7rt8Ddd\ -7drf_nTD1QxESVhYqKTax5Qfd-aq8gZz8gJCzS0yyfQh6DmdhmwgrSCCRC6BUQkeFNvj\ -MVEYHQ9fr0NA -&client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertio\ -n-type%3Ajwt-bearer -&client_id=a2c36919-01ff-4810-a829-400fad357351 -&token=eyJhbGciOiJSUzI1NiJ9.eyJleHAiOjE0MTg3MDI0MTQsImF1ZCI6WyJlNzFm\ -YjcyYS05NzRmLTQwMDEtYmNiNy1lNjdjMmJjMDAzN2YiXSwiaXNzIjoiaHR0cHM6XC9c\ -L2FzLXZhLmV4YW1wbGUuY29tXC8iLCJqdGkiOiIyMWIxNTk2ZC04NWQzLTQzN2MtYWQ4\ -My1iM2YyY2UyNDcyNDQiLCJpYXQiOjE0MTg2OTg4MTR9.FXDtEzDLbTHzFNroW7w27RL\ -k5m0wprFfFH7h4bdFw5fR3pwiqejKmdfAbJvN3_yfAokBv06we5RARJUbdjmFFfRRW23\ -cMbpGQCIk7Nq4L012X_1J4IewOQXXMLTyWQQ_BcBMjcW3MtPrY1AoOcfBOJPx1k2jwRk\ -YtyVTLWlff6S5gK-ciYf3b0bAdjoQEHd_IvssIPH3xuBJkmtkrTlfWR0Q0pdpeyVePkM\ -SI28XZvDaGnxA4j7QI5loZYeyzGR9h70xQLVzqwwl1P0-F_0JaDFMJFO1yl4IexfpoZZ\ -sB3HhF2vFdL6D_lLeHRy-H2g2OzF59eMIsM_Ccs4G47862w -¶ -
- The client assertion parameter is structured as described in - Section 2.5.2 - .¶
-The server responds to an introspection request with a JSON - object representing the token containing the following fields as - defined in the token introspection specification:¶
-The following example is a response from the introspection - endpoint:¶
-HTTP/1.1 200 OK
-Date: Tue, 16 Dec 2014 03:00:14 GMT
-Access-Control-Allow-Origin: *
-Content-Type: application/json;charset=ISO-8859-1
-Content-Language: en-US
-Content-Length: 266
-Connection: close
-
-{
- "active": true,
- "scope": "file search visa",
- "exp": 1418702414,
- "sub": "{sub\u003d6WZQPpnQxV, iss\u003dhttps://idp-p.example.com/}",
- "client_id": "e71fb72a-974f-4001-bcb7-e67c2bc0037f",
- "token_type": "Bearer"
-}
-¶
-- The authorization server MUST require authentication for both the - revocation and introspection endpoints as described in - Section 2.5.2. Protected resources calling the - introspection endpoint MUST use - credentials distinct from any other - OAuth client registered at the - server.¶
-A protected resource MAY cache the response from the - introspection endpoint for a period of time no greater than half - the - lifetime of the token. A protected resource MUST NOT accept a - token - that is not active according to the response from the - introspection - endpoint.¶
-The following data will be sent as an Authorization Response to - the Authorization Code Flow as described above. The authentication - response is sent via HTTP redirect to the redirect URI specified in - the request.¶
-- The following fields MUST be included in the response:¶
-- PKCE parameters MUST be associated with the "code" as per Section 4.4 of - Proof Key for Code Exchange by OAuth Public Clients (PKCE) [RFC7636]¶
-The following is an example response:¶
--https://https://client.example.org/cb? - state=2ca3359dfbfd0 - &code=gOIFJ1hV6Rb1sxUdFhZGACWwR1sMhYbJJcQbVJN0wHA -¶ -
Access tokens SHOULD have a valid lifetime no greater than one hour, and - refresh tokens (if issued) SHOULD have a valid lifetime no greater - than twenty-four hours. Specific applications MAY issue tokens with different lifetimes. - Any active token MAY be revoked at any time.¶
-In addition to the lifetime of the token, protected resources may specify a maximum age of the - authentication events that led to access tokens they receive by including the max_age claim - in authorization requests and examining the auth_time claim value in access tokens.¶
-Scopes define individual pieces of authority that can be - requested - by clients, granted by resource owners, and enforced by - protected - resources. Specific scope values will be highly dependent - on the - specific types of resources being protected in a given - interface. - OpenID Connect, for example, defines scope values to - enable access - to - different attributes of user profiles.¶
-Authorization servers SHOULD define and document default scope - values that will be used if an authorization request does not - specify - a requested set of scopes.¶
-To facilitate general use across a wide variety of protected - resources, authorization servers SHOULD allow for the use of - arbitrary - scope values at runtime, such as allowing clients or - protected - resources to use arbitrary scope strings upon - registration. - Authorization servers MAY restrict certain scopes from - use by - dynamically registered systems or public clients.¶
-Protected Resources grant access to clients if they present a valid sender-constrained
- access_token with the appropriate
- scope. Resource servers trust the
- authorization server to authenticate the end user and client appropriately
- for the importance, risk, and value level of the protected
- resource scope.¶
Protected resources that require a higher end-user authentication trust - level to access certain resources MUST associate those resources with a - unique scope.¶
-- Clients wishing access to these higher level resources MUST include the - higher level scope in their authorization request to the authorization server.¶
- Authorization servers MUST authenticate the end-user with the appropriate
- trust level before providing an authorization_code
- or associated access_token to the client.¶
Authorization servers MUST only grant access to higher level scope resources to - clients that have permission to request these scope levels. Client authorization - requests containing - scopes that are outside their permission MUST be rejected.¶
-Authorization servers MAY set the expiry time (exp)
- of access_tokens associated with higher level resources to be shorter than
- access_tokens for less sensitive resources.¶
Authorization servers MAY allow a refresh_token
- issued at a higher level to be
- used to obtain an access_token for a lower level resource scope with an
- extended expiry time. The client MUST request both the higher level scope and
- lower level scope in the original authorization request. This allows clients to
- continue accessing lower level resources after the higher level resource access
- has expired -- without requiring an additional user authentication/authorization.¶
For example: a resource server has resources classified as "public" and "sensitive".
- "Sensitive" resources require the user to perform a two-factor authentication,
- and those access grants are short-lived: 15 minutes.
- For a client to obtain access to both "public" and "sensitive" resources,
- it makes an authorization request to the authorization server with
- scope=public+sensitive. The authorization
- server authenticates the end-user as required to meet the required trust level
- (two-factor authentication or some approved equivalent) and issues an
- access_token for the "public" and "sensitive" scopes
- with an expiry time of 15mins, and a refresh_token
- for the "public" scope with an expiry time of 24 hrs. The client can access both
- "public" and "sensitive" resources for 15mins with the access_token. When the
- access_token expires, the client will NOT be able to access "public" or "sensitive"
- resources any longer as the access_token has expired, and must obtain a
- new access_token. The client makes a
- access grant request (as described in OAuth 2.0 [RFC6749]
- section 6) with the refresh_token,
- and the reduced scope of just "public". The token endpoint validates the refresh_token,
- and issues a new access_token for just the "public" scope with an expiry time set to 24hrs.
- An access grant request for a new access_token with the "sensitive" scope would be
- rejected, and require the client to get the end-user to re-authenticate/authorize the
- "sensitive" scope request.¶
In this manner, protected resources and authorization servers work together to meet - risk tolerance levels for sensitive resources and end-user authentication.¶
-- A protected resource MUST accept bearer tokens passed in the - authorization header as described in - [RFC6750] - . A - protected resource MUST NOT accept bearer tokens passed in the - form - parameter or query parameter methods.¶
-Protected resources MUST define and document which scopes are - required for access to the resource.¶
-If a client uses the mTLS [RFC8705] method to sender-constrain tokens, the protected resource - MUST verify that the certificate matches the certificate associated with the - access token. If they do not match, the resource access attempt MUST be denied. - The client SHOULD use a certificate to sender-constrain tokens that is distinct from the certificate used to connect - to the protected resource.¶
-Protected resources MUST interpret access tokens using either - JWT, - token introspection, or a combination of the two.¶
-
- The protected resource MUST check the
- aud
- (audience) claim, if it exists in the token, to ensure that it
- includes the protected resource's identifier. The protected
- resource
- MUST ensure that the rights associated with the token are
- sufficient
- to grant access to the resource. For example, this can be
- accomplished
- by querying the scopes and acr associated with the token from
- the
- authorization server's token introspection endpoint.¶
A protected resource MUST limit which authorization servers it - will - accept valid tokens from. A resource server MAY accomplish - this using - a whitelist of trusted servers, a dynamic policy engine, - or other - means.¶
-For a comprehensive protection against network attackers, all endpoints should additionally use DNSSEC to protect - against DNS spoofing attacks that can lead to the issuance of rogue domain-validated TLS certificates.¶
-Authorization servers, clients, and protected resources SHOULD consider internet best practices from - OAuth 2.0 Security Best Current Practice [SecBCP], - JSON Web Token Best Current Practices [RFC8725] and - JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens [RFC9068] that are not - explicitly REQUIRED or RECOMMENDED in this profile.¶
-Authorization Servers SHOULD take into account device posture when dealing - with native apps if possible. Some examples of device posture include:¶
-the user's lock screen setting¶
-the app's level of privilege over the device operating system (e.g. if the app has 'root access', the - device operating system may be compromised to gain additional privileges not intended by the vendor)¶
-the availability of a device attestation to validate the app¶
-- Specific policies or capabilities are outside the scope of this specification.¶
-- This profile does not protect against the attacks described in - The Stronger Attacker Model [SAM], in which an attacker - could inject the authorization request and read the authorization response. - Although using request object signatures would provide mitigation, this profile does not require - request object signatures because of the lack of available implementations.¶
-This profile addresses the privacy threats identified in Privacy Considerations for Internet Protocols [RFC6973] with normative - language throughout the document. In particular, this profile requires the use of TLS for all network connections, PKCE, and sender constrained tokens - to mitigate the threats in [RFC6973]¶
-In OpenID Connect implementations, servers and clients SHOULD implement the privacy threat mitigations in Section 17 of - OpenID Connect Core 1.0 [OpenID.Core].¶
-The OpenID Community would like to thank the following people for - their contributions to this specification: Mark Russel, Mary - Pulvermacher, David Hill, Dale Moberg, Adrian Gropper, Eve Maler, - Danny van Leeuwen, John Moehrke, Aaron Seib, John Bradley, Debbie - Bucci, Josh Mandel, Sarah Cecchetti, Giuseppe De Marco, Joseph Heenan, - Jim Fenton, Ryan Galluzzo, Bjorn Hjelm, and Michael B. Jones.¶
-Special thank you to the original iGov Profile editors: Paul Grassi, Justin Richer, - and Michael Varley.¶
-The original version of this specification was part of the Secure - RESTful Interfaces project from The MITRE Corporation, available - online - at http://secure-restful-interface-profile.github.io/pages/¶
-Copyright (c) 2025 The OpenID Foundation.¶
-The OpenID Foundation (OIDF) grants to any Contributor, developer, implementer, or other interested party a non-exclusive, royalty free, worldwide copyright license to reproduce, - prepare derivative works from, distribute, perform and display, this Implementers Draft, Final Specification, or Final Specification Incorporating Errata Corrections solely for the - purposes of (i) developing specifications, and (ii) implementing Implementers Drafts, Final Specifications, and Final Specification Incorporating Errata Corrections based on such - documents, provided that attribution be made to the OIDF as the source of the material, but that such attribution does not indicate an endorsement by the OIDF.¶
-The technology described in this specification was made available from contributions from various sources, including members of the OpenID Foundation and others. Although the - OpenID Foundation has taken steps to help ensure that the technology is available for distribution, it takes no position regarding the validity or scope of any intellectual property - or other rights that might be claimed to pertain to the implementation or use of the technology described in this specification or the extent to which any license under such rights - might or might not be available; neither does it represent that it has made any independent effort to identify any such rights. The OpenID Foundation and the contributors to this - specification make no (and hereby expressly disclaim any) warranties (express, implied, or otherwise), including implied warranties of merchantability, non-infringement, fitness - for a particular purpose, or title, related to this specification, and the entire risk as to implementing this specification is assumed by the implementer. The OpenID Intellectual - Property Rights policy (found at openid.net) requires contributors to offer a patent promise not to assert certain patent claims against other contributors and against implementers. - OpenID invites any interested party to bring to its attention any copyrights, patents, patent applications, or other proprietary rights that may cover technology that may be required - to practice this specification.¶
-[[ To be removed from the final specification ]]¶
-- -05¶
-- Updated BCP mitigations, aligned with FAPI¶
-- Harmonized cryptography, sender constrained tokens with FAPI¶
-- Added requirement and optionality for authentication context and support for Step-up (RFC 9470)¶
-- Added Privacy Considerations (RFC 6973)¶
-- Added optionality to support enterprise tailoring, especially RFC 8705 mTLS with PKI¶
-- -04¶
-- Enable building with https://author-tools.ietf.org/.¶
-- Applied OpenID specification conventions.¶
-- -03¶
-- First Implementer's Draft¶
--2017-06-01¶
-Aligned with prior version of iGov.¶
-Added guidance text around using scopes and refresh_tokens to protect sensitive resources.¶
-Removed ACR reference.¶
--2018-05-07¶
-Imported content from HEART OAuth profile.¶
-