OAuth 2.0 and OpenID Connect 1.0 are different types of protocols and they are often confused. When we talk about IAM (identity and access management), we should distinguish between AuthZ and AuthN:
- AutheNtication (AuthN, aka Identity Management) is about validating user’s identity by verifying that the user trying to connect is actually who it claims itself to be;
- AuthoriZation (AuthZ, aka Access Management) refers to granting or denying access to specific resources based on the requesting user’s identity. It is usually performed after a user is identified through authentication. The most common approach is Role-Based Access Control (RBAC).
OAuth was developed by Twitter and Google in 2006 as an open standard for API authorization. OAuth 2.0 is published in 2012. It allows user to delegate authorization. For example, a user signed up to a new application and allows it to automatically import her facebook contact. In this case the application accesses Facebook contact API on behalf of the user. Authorization Server(Facebook) issues token to the application with user’s approval. Note that the user did NOT log in to the application with her Facebook account. She had been authenticated already, and was simply importing contact after logging in. The roles involved in OAuth 2.0 are:
Resource: the contact list of the user
Resource owner: the user
Client: the application
Resource Server: contact.facebook.com
Authorization Server: accounts.facebook.com
This page has further details for each step.
OAuth 2.0 is an inherently insecure protocol since it does not support signature, encryption, channel binding or client verification. The protocol relies entirely on the underlying transport layer security (TLS) to provide confidentiality and integrity.
OpenID Connect (OIDC) 1.0
OpenID Connect is an open standard for authentication, promoted by the non-profit OpenID Foundation. It allows user to be authenticated using a third-party service called identity providers. User may choose to use their preferred OpenID Connect providers to log in to websites that accept the OpenID Connect authentication scheme. For example, a user uses her Facebook to login to an online application.
OpenID Connect is an extension to OAuth 2.0 with a few additions:
- In addition to access token, an ID token is returned by the authorization server;
- Userinfo end point is provided in case Id token is not sufficient and more user information is needed;
- “openid” is passed as a parameter in the Scope during the initial call to the authorization server;
Therefore OpenID Connect is considered an identity layer on top of OAuth 2.0. Many application supports OpenID Connect such as Apache Nifi.
OIDC is comparible with SAML in the sense that both provide SSO feature (federated identity). Here is a comparison table:
|Main Purpose||SSO for consumer/mobile applications||SSO for enterprise applications|
|Load||Relatively light weight||Heavy weight due to the size of XML messages|
|Use case||Satisfies both authentication and authorization use cases, often combined with OAuth 2.0||Generally not used for API security|
|Transport||HTTP GET and HTTP POST||HTTP Redirect (GET) binding, SAML SOAP binding, HTTP POST binding, et|
Here are more details about their differences.
Authentication with OIDC vs pseudo-authentication using OAuth 2.0
OpenID Connect is an authentication protocol for the purpose of validating user’s identity. OAuth 2.0 is an authorization protocol.
In OpenID Connect, the response from identity provider is an assertion of identity. In comparison, many implementations uses OAuth 2.0 on its own as an authentication method, which is referred to as pseudo-authentication. In such pseudo-authentication, the response from identity provider is an access token that may grant the client application ongoing access to some of the identity provider’s APIs, on behalf of the user. The access token acts as a kind of “valet key” that the application can include with its request to the identity provider, as a proof that it has user’s permission to access the APIs.
Because the identity provider typically (but not always) authenticates the user as part of the process of granting an OAuth access tokent, it’s tempting to view a sccessful OAuth access token request as an authentication method itself. However, because OAuth was not designed with this use case in mind, making this assumption can lead to major security flaws.