OpenID Connect Profile (Code only)

Owned by Former user (Deleted)
Last updated: Aug 21, 2014
10 min read

Security Analysis 

The following table breaks down the assertion based threats from SP-800-63 (ISO29115 comparison to be added) by Level of Assurance, and lists OIDC's mitigations of those threats.

The green shading indicates that Connect supports the feature.

Assertions:
Assertions are statements from a Verifier to an RP that contain information about a Subscriber.		Mitigation Required at LoA 

Threat

SP800-63 Mitigations

1

2

3

4

OIDC Mitigations

Assertion manufacture/modification: An Attacker may generate a bogus assertion or modify the assertion content (such as the authentication or attribute statements) of an existing assertion, causing the RP to grant inappropriate access to the Subscriber.

1. The assertion may be digitally signed by the Verifier. The RP should check the digital signature to verify that it was issued by a legitimate Verifier.

2. The assertion may be sent over a protected session such as TLS/SSL. In order to protect the integrity of assertions from malicious attack, the Verifier shall be authenticated.

Y

Y

Y

Y

  • OIDC Core, Section 16.11: “For the HTTP binding defined by this specification, the responses to Token Requests are bound to the corresponding requests by message order in HTTP, as both the response containing the token and requests are protected by TLS, which will detect and prevent packet reordering.”
  • JSON Web Signature

In OIDC Core,i t’s not clear where the requirement that the “assertion consumer” endpoint, i.e., JWT consumer endpoint, MUST be TLS .   This could be addressed in the profile, under Client Registration

Assertion disclosure: Assertions may contain authentication and attribute statements that include sensitive Subscriber information. Disclosure of the assertion contents can make the Subscriber vulnerable to other types of attacks.

1. The assertion may be sent over a protected session to an authenticated RP.

2. If assertions are signed by the Verifier, they may be encrypted for a specific RP with no additional integrity protection.

N

Y

Y

Y

Assertion repudiation by the Verifier: An assertion may be repudiated by a Verifier if the proper mechanisms are not in place. For example, if a Verifier does not digitally sign an assertion, the Verifier can claim that it was not generated through the services of the Verifier.

The assertion may be digitally signed by the Verifier using a key that supports non-repudiation. The RP should check the digital signature to verify that it was issued by a legitimate Verifier.

N

N

Y

Y

 

Assertion repudiation by the Subscriber: Since it is possible for a compromised or malicious subscriber to issue assertions to the wrong party, a subscriber can repudiate any transaction with the RP that was authenticated using only a bearer assertion.

To mitigate this threat, the Verifier may issue holder of key, rather than bearer assertions. The Subscriber can then prove possession of the asserted key to the RP. If the asserted key matches the subscriber’s long term credential (as provided by the CSP) it will be clear to all parties involved that it was the Subscriber who authenticated to the RP rather than a compromised Verifier impersonating the Subscriber.

N

N

N

Y

  • This is currently being worked on in OAuth for JWT.  For use in general deployment browser support for channel ID is required.  Support for a limited set of web clients with TLS client Auth support(like SAML POP) will be available first.
  • PoP support for binding AT to clients is also part of this work.

Assertion redirect: An Attacker uses the assertion generated for one RP to obtain access to a second RP.

To mitigate this threat, the assertion may include the identity of the RP for whom it was generated. The RP verifies that incoming assertions include its identity as the recipient of the assertion.

N

Y

Y

Y

  • OIDC ID Tokens are JWT. 
  • OIDC Core, Section 2:
    aud:REQUIRED. Audience(s) that this ID Token is intended for. It MUST contain the OAuth 2.0 client_id of the Relying Party as an audience value.
  • OIDC Core, Section 3.1.3.7
    The Client MUST validate that the aud (audience) Claim contains its client_id value registered at the Issuer identified by the iss (issuer) Claim as an audience.

Assertion reuse: An Attacker attempts to use an assertion that has already been used once with the intended RP.

To mitigate this threat, the following mechanisms may be used:

1. The assertion includes a timestamp and has a short lifetime of validity.The RP checks the timestamp and lifetime values to ensure that the assertion is currently valid. The lifetime value may either be in the assertion or set by the RP.

2. The RP keeps track of assertions that were consumed within a (configurable) time window to ensure that an assertion cannot be used more than once within that time window.

Y

Y

Y

Y

  • OIDC Core, Section 3.1.3.7
    9. The current time MUST be before the time represented by the exp Claim.
    10. The iat Claim can be used to reject tokens that were issued too far away from the current time, limiting the amount of time that nonces need to be stored to prevent attacks. The acceptable range is Client specific.
Secondary authenticators:
Secondary authenticators include assertions in the direct model, session keys in Kerberos, assertion references in the indirect model, and cookies used for authentication.		Mitigation Required at LoA 

Threat

SP800-63 Mitigations

1

2

3

4

OIDC Code Flow -

Secondary authenticator manufacture: An Attacker may attempt to generate a valid secondary authenticator and use it to impersonate a Subscriber.

To mitigate this threat, one of the following mechanisms may be implemented:

1. The secondary authenticator may contain sufficient entropy that an Attacker without direct access to the Verifier’s random number generator cannot guess the value of a valid secondary authenticator.

2. The secondary authenticator may contain timely assertion data that is signed by the Verifier or integrity protected using a key shared between the Verifier and the RP.

3. The Subscriber may authenticate to the RP directly using his or her long term token and avoid the need for a secondary authenticator altogether.

Y

Y

Y

Y

  • OIDC Core,
    --3.1.2.1 (meets #1 on left) OPTIONAL. 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 Authorization Request to the ID Token. Sufficient entropy MUST be present in the nonce values used to prevent attackers from guessing values
    -- 3.1.3.1, Token Request: (meets #3 on left) If the Client is a Confidential Client, then it MUST authenticate to the Token Endpoint using the authentication method registered for its client_id

Secondary authenticator capture: The Attacker may use a session hijacking attack to capture the secondary authenticator when the Verifier transmits it to the Subscriber after the primary authentication step, or the Attacker may use a man-in-the-middle attack to obtain the secondary authenticator as it is being used by the Subscriber to authenticate to the RP. If, as in the indirect model, the RP needs to send the secondary authenticator back to the Verifier in order to check its validity or obtain the corresponding assertion data, an Attacker may similarly subvert the communication protocol between the Verifier and the RP to capture a secondary authenticator. In any of the above scenarios, the secondary authenticator can be used to impersonate the Subscriber.

To mitigate this threat, adequate protections shall be in place throughout the lifetime of any secondary authenticators used in the assertion protocol.

1. In order to protect the secondary authenticator while it is in transit between the Verifier and the Subscriber, the secondary authenticator shall be sent via a protected session established during the primary authentication of the Subscriber using his or her token. This requirement is the same as the requirement in Section 8, regarding the Authentication Process, to protect sensitive data (in this case the secondary authenticator)from session hijacking attacks.

2. In order to protect the secondary authenticator from capture as it is submitted to the RP, the secondary authenticator shall be used in an authentication protocol which protects against eavesdropping and man-inthe-middle attacks.

3. In order to protect the secondary authenticator after it has been used, it shall never be transmitted on an unprotected session or to an unauthenticated party while it is still valid. The secondary authenticator may be sent in the clear only if the sending party has strong assurances that the secondary authenticator will not subsequently be accepted by any other RP. This is possible if the secondary authenticator is specific to a single RP, and if that RP will not accept secondary authenticators with the same value until the maximum lifespan of the corresponding assertion has passed.

N

Y

Y

Y

  • OIDC Core, Section 3.1.3 Communication with the Token Endpoint MUST utilize TLS.

 

 

Assertion Binding:
the binding between the secret used to authenticate to the RP and the assertion data referring to the Subscriber shall be strong.		Mitigation Required at LoA 

Threat

SP800-63 Mitigations

1

2

3

4

OIDC Mitigations

Assertion substitution: A subscriber may attempt to impersonate a more privileged subscriber by subverting the communication channel between the Verifier and RP, for example by reordering the messages, to convince the RP that his or her secondary authenticator corresponds to assertion data sent on behalf of the more privileged subscriber. This is primarily a threat to the indirect model, since in the direct model, assertion data is directly encoded in the secondary authenticator.

To mitigate this threat, one of the following mechanisms may be implemented:

1. Responses to assertion requests, signed or integrity protected by the Verifier, may contain the value of the assertion reference used in the request or some other nonce that was cryptographically bound to the request by the RP.

2. Responses to assertion requests may be bound to the corresponding requests by message order, as in HTTP, provided that assertions and requests are protected by a protocol such as TLS that can detect and disallow malicious reordering of packets.

N

Y

Y

Y

 

       

 

Notes

At Level 1, it must be impractical for an Attacker to manufacture an assertion or assertion reference that can be used to impersonate the Subscriber. If the direct model is used, the assertion which is used shall be signed by the Verifier or integrity protected using a secret key shared by the Verifier and RP, and if the indirect model is used, the assertion reference (code) which is used shall have a minimum of 64 bits of entropy. Bearer assertions (id_tokens) shall be specific to a single transaction.  Also, if assertion references are used, they shall be freshly generated whenever a new assertion is created by the Verifier. In other words, bearer assertions and assertion references are generated for one-time use.

Furthermore, in order to protect assertions against modification in the indirect model, all assertions sent from the Verifier to the RP shall either be signed by the Verifier, or transmitted from an authenticated Verifier via a protected session. In either case, a strong mechanism must be in place which allows the RP to establish a binding between the assertion reference and its corresponding assertion, based on integrity protected (or signed) communications with the authenticated Verifier.

To lessen the impact of captured assertions and assertion references, assertions that are consumed by an RP which is not part of the same Internet domain as the Verifier shall expire if they are not used within 5 minutes of their creation. Assertions intended for use within a single Internet domain, including assertions contained in or referenced by cookies, however, may last as long as 12 hours without being used

 

 Technical Requirements

 

1  Client Registration

  1. The Server MUST allow for registration of Redirect URI (redirect_uris).  Per the OpenID Connect specification exact matching of Redirect URI is required to be performed by the Server.
  2. The server SHOULD allow for the registration of a public key by the client (jwks_uri or jwks) and a Token Endpoint Authentication method (token_endpoint_auth_method) of private_key_jwt but may support a method of  client_secret_jwt or client_secret_basic by returning a client secret with greater than xx entropy.
  3. Clients MAY indicate the required Authentication context “acr” as part of the client registration process or dynamically as part of a Connect Authorization request.
    1. Trust frameworks using this profile SHOULD use short names for Authentication Contexts that are registered in the IANA registry,   Full URI may also be used as names, but are not recommended.
  4. The Authorization Server SHOULD provide a way during registration for Clients to register the following:
    1. Authentication time claim in the id_token is REQUIRED:  (require_auth_time) True/False
    2. Maximum Authentication Age:  (default_max_age) Specifies that the End-User MUST be actively authenticated if the End-User was authenticated longer ago than the specified number of seconds. The max_age request parameter overrides this default value. If omitted, no default Maximum Authentication Age is specified.
    3. Default Authentication Context Class Reference (default_acr_values) An array of strings that specifies the default acr values that the OP is being requested to use for processing requests from this Client, with the values appearing in order of preference.

      OpenID Connect Dynamic registration is preferred for registering these values, but other out of band methods may be used, or the values may be provided dynamically as part of the authentication request.

 

2 User Consent

  1. Clients and Personally Identifiable Information (PII)
    1. The Authorization Server MUST prompt the Resource Owner to explicitly consent to the release of any claims or scopes requested by the Client.  
      The Authorization Server must not provide claims or scopes that have been declined by the Resource Owner. 
      The Authorization server MAY cache authorization for a client across sessions to avoid re-prompting the user for consent already granted.


3  Identity Assertions

  1.  The Authorization Server MUST utilize the method in Sec 3.1 of OpenID Connect Core to return an assertion to the Client. 
  2. The Authorization Server MUST provide a JWT id_token which provides the following claims to the Client about the individual granting authorization (Resource Owner).
    1. Issuer Name:  “iss” The domain of the Authorization Server such that when paired with the user identifier creates a globally unique identifier. 
      1. The issuer name SHOULD be an https: scheme URI and MUST be under the control of the Authorization Server.
    2. User Identifier:  “sub” A persistent identifier for the Resource Owner granting authorization to the Client to access the authentication information endpoint. 
      1. The User Identifier MUST be a unique, opaque and not re-assignable identifier for the user. 
    3. Audience Restriction:  “aud” specifies the Client for whom the identity information is intended. 
      1. The Audience Restriction MUST be the client_id of the Client requesting the authentication.
    4. Issuance Time Stamp : “iat” The time that the Authorization Server issued the identity assertion.
    5. Expiration Time Stamp: "exp" The time after which the JWT must not be accepted for processing.
    6. Nonce:  “nonce” A value tying the identity assertion to a browser session.  This MUST be present if the client provided a nonce value in the request. 
  3. The Authorization Server SHOULD include the following claims in the Identity Assertion:
    1. Authentication Context: The Authentication Context Class reference for the authentication event.
      1. If the Client request Authn Context during the registration process, or requested it via the Authorization request, the Authz server MUST include it in the response.
    2. Authentication Time: A timestamp indicating when End-User authentication last occurred.
    3. JWT ID: "jti" A unique identifier for the id_token. 

 

  1. The Identity Token MUST be digitally signed.
    1. The Identity Token MAY be digitally signed using a FIPS-140 approved algorithm (e.g. RSA or ECDSA) using a trusted key.


  2. The Identity Token MAY be encrypted for the Client.

  3. Clients MUST verify the integrity and authenticity of the Identity Token per Section 3.1.3.7 of OpenID Connect Core.

 

5        Directed Identity


  1. Clients may Discover if an Authorization server supports Directed identity by using Discovery and inspecting the "subject_types_supported" element in the meta-data.
    1. The Authorization server meta-data will list "pairwise" as an option if it is supported.
  2. The client MUST register a "subject_type" of "pairwise" per Section 2 of OpenID Connect Dynamic Client registration.
  3. The client SHOULD register a sector_identifier_uri per Section 2 of OpenID Connect Dynamic Client registration.
    1.  The sector_identifier_uri and its associated file of redirect URI is described in Section 5 of OpenID Connect Dynamic Client registration, and allow for multiple redirect_URI and clients to share the same Pairwise identifiers.

 

6  Error Response

The Authorization Server must respond with an HTTP 400 (Bad Request) response on authentication or authorization error and include a status as defined in the original OAuth spec section 5.2. Error Response

 

7  Security

1.     The Authentication Information Endpoint may be part of an existing API.

2.     The Authorization Server must provide a Scope that provides an Identity Assertion to the Client with only the elements from 2.