Concepts
Token endpoint
Token endpoint To obtain an Access Token, an ID Token, and optionally a Refresh Token, the RP (Client) sends a Token Request to the Token Endpoint to obtain a Token Responses. Request URL:
|
1 |
https://identify.safewhere.com/runtime/oauth2/token.idp |
URI parameters: Parameter Description client_id The […]
Terminology
Terminology OAuth 2.0 – Common workflow The client submits an authorization request to the server, which validates that the client is a legitimate client of its service. The server redirects the client to the content provider to request access to […]
Support Authorization code grant
Support Authorization code grant (PKCE) OAuth 2.0 public clients using the Authorization Code Grant are susceptible to the authorization code interception attack. The Identify’s OAuth 2 implementation fully supports Authorization code grant (PKCE) which can mitigate against the threat through […]
OAuth2.0 session management with SSO/SLO scenario
OAuth2.0 session management with SSO/SLO scenario Identify OAuth 2.0 has full support for the session management specification. Discovery endpoint You can check the discovery endpoint of your Identify instance to see if the check_session_iframe and the end_session_endpoint feature have been […]
OAuth 2.0 – Resource Owner Password Credentials grant
OAuth 2.0 – Resource Owner Password Credentials grant Overview
|
1 |
NOTE: Resource Owner Password Credentials Grant will be deprecated in OAuth 2.1. Please think twice before using this. |
The Resource Owner Password Credentials Grant (defined in RFC 6749, section 4.3) can be used directly as an authorization grant to obtain an access token, and optionally a refresh token. […]
Client authentication support: private_key_jwt
Client authentication support: private_key_jwt Identify OAuth 2.0 service provider allows its users to authenticate their clients with a private_key_jwt method. When an authorization server authenticates its clients with the private_key_jwt method, the clients must send a request that contains an […]
Pairwise Pseudonymous Identifier (PPID)
Pairwise Pseudonymous Identifier (PPID) Per the OpenID Connect core specification:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
Pairwise Pseudonymous Identifier (PPID) Identifier that identifies the Entity to a Relying Party that cannot be correlated with the Entity's PPID at another Relying Party. Personally Identifiable Information (PII) Information that (a) can be used to identify the natural person to whom such information relates, or (b) is or might be directly or indirectly linked to a natural person to whom such information relates. Relying Party (RP) OAuth 2.0 Client application requiring End-User Authentication and Claims from an OpenID Provider. Sector Identifier Host component of a URL used by the Relying Party's organization that is an input to the computation of pairwise Subject Identifiers for that Relying Party. |
Identify supports both public and pairwise subject types as follows: public: Each client receives the same subject (sub) value. pairwise: Each client receives a different subject (sub) value to […]
OAuth 2.0 – Device flow
OAuth 2.0 – Device flow Overview The device flow is designed for devices that either do not have access to a browser or have limited input capabilities. This flow allows users to share specific data with an application while keeping […]
Client credentials flow for OpenId Connect and OAuth 2.0
Client credentials flow for OpenId Connect and OAuth 2.0 Overview With Client Credentials Flow (defined in RFC 6749, section 4.4) a Non Interactive Client (a CLI, a daemon, or a Service running on your backend), can directly ask Identify for […]
Passing Request parameters as JWTs
Passing Request parameters as JWTs The request Authorization Request parameter enables OpenID Connect requests to be passed in a single, self-contained parameter and to be optionally signed and/or encrypted. It represents the request as a JWT whose Claims are the […]