194
OpenID is a protocol for authentication while OAuth is for authorization. Authentication is about making sure that the guy you are talking to is indeed who he claims to be. Authorization is about deciding what that guy should be allowed to do.
In OpenID, authentication is delegated: server A wants to authenticate user U, but U's credentials (e.g. U's name ...
99
Simple Terms
OpenID is about verifying a person's identity (authentication).
OAuth is about accessing a person's stuff (authorization).
OpenID Connect does both.
All three let a person give their username/password (or other credential) to a trusted authority instead of to a less trusted app.
More Details
To understand something, look at its history.
...
83
OpenID connect will give you an access token plus an id token.
The id token is a JWT and contains information about the authenticated user. It is signed by the identity provider and can be read and verified without accessing the identity provider.
In addition, OpenID connect standardizes quite a couple things that oauth2 leaves up to choice. for instance ...
58
Many people still visit this so here's a very simple diagram to explain it
Courtesy Wikipedia
36
I don't think either of the other previous responses answer the question, which is asking the difference between OpenID Connect and OpenID 2.0. OpenID 2.0 is not OAuth 2.0.
OpenID 2.0 and OpenID Connect are very different standards with completely different parameters and response body formats. Both are built on top of OAuth 2.0 by putting additional ...
30
OAuth provides only and should only provides authorization using an access token. OpenID connect is built on OAuth 2 in order to provide user authentication information. However, it will not provide you a more robust implementation than OAuth (since it uses OAuth and add some extra interactions with a OpenID provider).
OpenID Connect 1.0 is a simple ...
24
@catanman makes excellent points regarding the technical considerations around PKCE in SPAs, however just recently the IETF Oauth working group has published a best current practice document (December 28, 2018) stating:
Note: although PKCE so far was recommended as a mechanism to
protect native apps, this advice applies to all kinds of OAuth
...
24
While all the other answers are correct, the latest OAuth 2.0 for Browser-Based Apps Best Practices Doc (January 29, 2019) states that (emphasis mine):
Overview
For authorizing users within a browser-based application, the best
current practice is to
o Use the OAuth 2.0 authorization code flow with the PKCE
extension
...
As well ...
22
OpenID and OpenID Connect are both for authentication, not for authorization. The two activities are distinct. OpenID Connect is in fact OAuth (an authorization protocol) which is turned (abused) into an authentication protocol. More explanations in this answer.
To some extent you can mix authentication and authorization, but that's a source of confusion. ...
21
From what you have explained it seems that OAuth 2.0 would better suit your needs. OpenID Connect was developed to add secure authentication to OAuth 2.0. Large providers i.e. Google, Facebook, Yahoo, etc began using OAuth 2.0 as a way to authenticate users with "login with" services so users could use their credentials to authenticate to a variety of third-...
18
tl;dr
Most security issues are with implementation and not protocol, the
simpler the better.
SAML/WS-Federation and OpenID Connect all use
cryptographically signed tokens that support optional encryption
SAML/WS-Fed is XML based and takes on the XML threat model while
OpenID Connect is JSON based {} and takes on the OAuth2 threat model
OpenID Connect ...
17
OAuth is an authorisation protocol, providing a way to give authorisation to access a protected resource. A by-product of the authorisation process is that the user is authenticated.
Technically, OAuth does not have to give you any information about the user. What it provides is a validation that the user has given authority to the application to access ...
17
Here is the difference between Implicit Flow and AuthCode Flow:
Implicit Flow
NOTE: As of April 2019, the Oauth Working Group no longer recommends the use of Implicit Flow for most cases because there are better, more secure ways to accomplish the same things.
User navigates to SPA, which redirects user to IdP to sign in.
User signs in (and authorizes the ...
17
SPAs would not benefit from PKCE. PKCE solves a different problem than the one you're describing.
First of all, for SPAs the current best practice is still to use the implicit flow, not the authorization code flow. With the implicit flow, the access token is included in the hash fragment (#) of the redirect URI instead of in a query component (?). Since the ...
11
We already have a diagram and a lot of good data so here is an example in case that helps.
Let's say I want to post a comment to StackOverflow. StackOverflow only allows comments if a user has 50 reputation.
StackOverflow must authorize this request (e.g. only allow it if the user has >= 50 rep). StackOverflow would not use OAuth to do this because ...
11
First off, as you probably know, OpenID Connect is just an authentication layer built on top of OAuth2. So regardless of which on you pick, you will need to implement OAuth2 (as the common denominator).
OAuth2 itself is an authorization mechanism (i.e. allows you to check that a token is valid and has a specific set of scopes granted). It does not provide ...
10
In addition to the other responses: I think that a lot of confusion comes from inacurrate, or at least unusual use of the terms Authentication and Authorization
OpenID Connect 1.0 is marketed as an Authentication solution, while it does not, by itself, handle the authentication. The "real" authentication in its basic sense (process of validating ...
9
The role concept can be used with access tokens in OpenID Connect (Oauth2).
Consider that a scope is a request for claims about the user that should be included in the access token. The API requesting access knows that it needs the (say) "employee" role, includes the "scope=openid roles" query parameter in the request.
The authentication server (AS) has ...
8
OpenID Connect is a profile of OAuth2... defining an architecture that enables a person to authorize an identity provider to release certain user claims to a client (website / mobile application).
OAuth2 offers the Resource Owner Password Credential Grant, which is rightly maligned by IAM experts as "The Devil".
A common pattern for OpenID Connect API is ...
7
I'm not sure about OpenID, but for OAuth there is no CORS involved for the actual authentication part, though it may be required on the resource server depending on the type of client that is connecting.
In RFC 6749, which defines the OAuth 2 framework, there are four different methods defined for the application to gain authorization (here, client means ...
6
OAuth provides only and should only provides authorization using an access token. OpenID connect is built on OAuth 2 in order to provide user authentication information. OpenID connect is in fact the child of OpenID. See OpenID-Connect-Lecture-for-MIT, slide 33
OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 [RFC6749] protocol. It ...
6
Yes this is a reasonable approach.
It is not a zero risk approach. If a user does not already have an OpenID Connect account, or they do not understand the concept, the sign up process becomes more difficult and you risk losing that user. Because you are doing something that is non-standard you will get some smart alec users who pester your support guys ...
6
The verification is not directly performed by you, so in principle yes, Google could fake the identity of any of its users upon authentication.
What happens during the authentication is that your service contact Google OpenID provider and asks: "who is this user?". Google answer will be along the lines of "this user is foo.bar@gmail.com and I have verified ...
6
The main issue is making sure that you protect against the confused deputy problem.
Imagine you are using OAuth to authenticate users within your application.
However, an evil developer has their own application which also uses OAuth. Say their application is a Solitaire game, which uses Google's OAuth API. A user authenticates for Solitaire using their ...
6
Reading your question, I believe the confusion stems from where the replay attack is taking place. The nonce prevents replay attacks against the client (your application), not the authorization server.
I understand that you're using the code flow, but for the sake of simplicity, let's assume you're using the implicit flow in a single-page application and ...
6
The jti (JWT ID) is chosen by the authentication server in order to identify a token. As per OpenID Connect, section 9:
JWT ID. A unique identifier for the token, which can be used to prevent reuse of the token. These tokens MUST only be used once, unless conditions for reuse were negotiated between the parties; any such negotiation is beyond the scope ...
5
No, I don't believe it is, though I am focusing on usability purposes more than security purposes which is perhaps not what you're referring to with this question due to where you posted it, but it is important to consider.
There are people, such as myself, that do not use any third party authentication service. To have these as the only login options would ...
5
Using OAuth as an authentication method is not recommended, it is explicitly designed as a delegated authorisation method.
Facebook was using OAuth as an authentication method, but an enterprising person discovered how to steal the access_token from Facebook - full blog entry
OpenID Connect makes it much more difficult to steal access tokens through such a ...
5
Looks like I found the answer on Access Token:
UserInfo Endpoint
It should be noted that clients are not required to use the access
token, since the ID Token contains all the necessary information for
processing the authentication event. However, in order to provide
compatibility with OAuth and match the general tendency for
authorizing ...
5
2020-12 UPDATE
There is an OAuth 2.1 draft to get rid of Implicit flow - short summary here. OAuth 2.1 brings together the latest OAuth 2 best practices.
TLDR; best to avoid Implicit flow if you can.
And more generally, why is the “Implicit“ flow frowned at?
Because the access token is exposed to the user agent (browser). See Implicit flow diagram in the ...
Only top voted, non community-wiki answers of a minimum length are eligible
