OpenID Connect Profile

Owned by Former user (Deleted)
Last updated: Feb 06, 2014
3 min read

 

 

1  Client Registration

  1. 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 there Authentication Contexts that are registered in the IANA registry,   Full URI may also be used as names, but are not recommended.
  2. Clients and Personally Identifiable Information (PII)
    1. The Authorization Server MUST prompt the Resource Owner to explicitly accept all scope parameters requested by the Client.  The Authorization Server must ignore any scope parameters received from the Client which the Resource Owner  forbidden 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.

 

2  Identity Assertions

  1. 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. Nonce:  “nonce” A unique value tying the identity assertion to a browser session.
  2. The Authorization Server SHOULD include the following claims in the Identity Assertion:
    1. Expiration Time Stamp: The time after which the identity assertion is no longer valid.
    2. Authentication Context: The Authentication Context Class reference for the authentication event.
      1. If the Client request Authn Context during the registration process the Authz server MUST include it in the response.
    3. Authentication Time: A timestamp indicating when the user logged into the
  3. Obtaining and Identity Assertion

The Authorization Server MUST utilize one of the method Sec 3.1 of OpenID Connect return an assertion to the Client.

 

4  Tokens

1.     The Authorization Server MUST return an Identity Token.  There are two ways to do this….

a.     If the  In addition to Authorization Grant, the Authorization Server MAY return an Identity Token.
 from the authorization endpoint or

b.     The Authorization Server MAY return the Identity Token in exchange when issuing the Access Token in exchange for the Authorization Grant and Client Credentials.

2.     The Identity Token MUST contain an identity assertion as defined in section 4.2.

a.     The Identity Token MUST be digitally signed.

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

The Identity Token MAY be digitally signed using an HMAC with the Client Secret.

                                             ii.     The Identity Token MAY be digitally signed using an HMAC with the Client Secret..

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

                                               i.     The Identity Token SHOULD be encrypted if passed through the browser to the Client.

3.     Clients MUST verify the integrity and authenticity of the Identity Token.

a.     Decrypt using the shared SHA-256 HMAC secret

b.     Check the signature.

c.     Check the audience, issuer and time stamps.

d.     Verify nonce if present.

4.     refresh_token MUST NOT be used in an authentication transaction.

 

5        Directed Identity

1.     End users MUST select an ICAM-approved Authorization Server from a list provided by the Client (e.g., set of clickable icons, dropdown menu selection). This use case is commonly referred to as "directed identity".

 

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 4.2.

3.     The Authorization Server must provide a way during registration for Clients to register the following:

a.     Authentication time REQUIRED  True/False

b.     Maximum Authentication Age:  If auth_time > max_auth_age then prompt user for interactive login.

c.     A grant_type of refresh_token is prohibited in this profile.