OIDC Integration Overview - Digital-Platform-Services/My-NS-Account GitHub Wiki
OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol. It enables Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an interoperable and REST-like manner.
OpenID Connect implements authentication as an extension to the OAuth 2.0 authorization process. Use of this extension is requested by Clients by including the openid scope value in the Authorization Request. Information about the authentication performed is returned in a JSON Web Token (JWT) called an ID Token. OAuth 2.0 Authentication Servers implementing OpenID Connect are also referred to as OpenID Providers (OPs). OAuth 2.0 Clients using OpenID Connect are also referred to as Relying Parties (RPs).
My NS Account supports both confidential and public clients using the Authorization Code Flow. The Implicit and Hybrid Flows are not supported, as per iGov.OAuth2 and CATS 3 requirements. latest doc https://openid.net/specs/openid-igov-oauth2-1_0.html
Refer to OIDC for complete details of the OpenID Connect protocol.
Confidential Client Authorization Code Flow
Confidential clients must pass the authentication request parameters as a JWT as defined in OIDC section 6. Requests to the Token Endpoint must use a client_assertion_type of urn:ietf:params:oauth:client-assertion-type:jwt-bearer and include a signed JWT for client authentication, as specified in RFC7523.
**Note: ** Confidential Client
- RP should host jwks_uri which includes public key from RP side and this needs to be reachable to IDP.
- Signing is MUST.
- Encryption is Optional also only applicable for Auth Request and Not for Token request and needs to be updated on RP metadata.
Public Client Authorization Code Flow
Public clients must perform Proof of Key Code Exchange (PKCE) with an S256 code challenge, as specified in iGov.OAuth2.
Authorization Code Flow Overview
