How is This Different From SAML 2.0?

2754 views June 12, 2017 August 9, 2017 3

In addition to that JSON is used instead of XML, there are some other important differences:

1. The user is in control of his data. OIDC trusts clients less than the SAML protocol does. The client can only access the users’ data (claims) when the user has authorized access to his data. The user is the legal owner of his personal data, and this construct ensures the protocol is aligned with that idea.

2. The client explicitly requests access to resources. Everything that we know about the user will be returned in the SAMLResponse. In OAuth 2.0 and OIDC, the client is expected to request access to data and services through Claims and scope. This aids in only transferring data that is actually necessary, and ensuring users can control what is actually divulged about h[im|er].

3. The client accesses resources directly. The SAMLResponse is transferred to clients through the user agent (browser) and is therefore impacted by user data transfer rates. OIDC resources are accessed by the client directly using access tokens and can therefore be done at any time and without involving the user further. This also ensures one does not put too much trust in the user’s user agent, by avoiding transfer of sensitive information through it, like SAML does.

4. Access granted to clients is not restricted to user information. An access token can be used for infinitely many things. As long as a resource server accepts an access token (and a scope value is defined for the action), the resource server can perform actions on behalf of the user. For instance, resource servers that create posts on your Facebook wall or change your profile information are real-life uses of this functionality.

5. The ID token is signed using a key that is publicly available on a standardized endpoint. The OIDC standard contains a public configuration endpoint where clients can fetch information about the authorization setup. Among the data the client can get from this endpoint, is the public part of the key that was used to sign the ID token. Therefore, signature key rotation is very simple, as all clients will (should) pick up new keys from this endpoint.

Was this helpful?