176
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 ...
85
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.
...
80
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 ...
79
What I see most commonly is allowing the authentication and signing the user in, but locking meaningful features away until the email is verified. You should bubble up an error reminding the user to re-send an activation email if they try to access one of the restricted features.
It is poor design to ever lie to a user - if they submit the correct username ...
58
Many people still visit this so here's a very simple diagram to explain it
Courtesy Wikipedia
57
This isn't a vulnerability of/in OAuth 2.0 at all. The issue has been wildly overblown and misstated by CNET and the original finder.
Here it is in a nutshell: If your web site (example.com) implements an open redirect endpoint - that is, implements a URL that will redirect the browser to any URL given in the URL parameters - AND your redirect copies URL ...
54
There are two ways you can save authentication information in the browser:
Cookies
HTML5 Web Storage
In each case, you have to trust that browsers are implemented correctly, and that Website A can't somehow access the authentication information for Website B. In that sense, both storage mechanisms are equally secure. Problems can arise in terms of how you ...
50
In my understanding, "less secure apps" refers to applications that send your credentials directly to Gmail. Lots of things can go wrong when you give your credentials to third party to give to the authentication authority: the third party might keep the credentials in storage without telling you, they might use your credentials for purposes outside the ...
39
Let's walk through how this attack works.
The Attack
I visit some client's website and start the process of authorizing that client to access some service provider using OAuth
The client asks the service provider for permission to request access on my behalf, which is granted
I am redirected to the service provider's website, where I would normally enter ...
33
Technically you can store the access token in your database, and use it for API calls until it expires. It might be more trouble than its worth, though.
For one thing, as Jonathan notes in his comment above, now you have to worry about securing your database and the data in it - these tokens give access to some fairly privileged information about your users....
29
Note: If you are looking for something like OAuth2, but for authentication, you should
use OpenId Connect instead.
OAuth2 is meant for a user to authorize an application to load the user's resources from some resource provider. In other words: OAuth2 is a mechanism for delegation of authorization. The protocol does not support authentication (although it ...
28
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 ...
23
State Parameter
The scope parameter is not used to secure the authentication request against CSRF attacks (see below). But there is another parameter called "state", which matches your description.
[Asking the user]
This step cannot be skipped.
I am afraid, this assumption is not correct. It is very common, that the user is only asked for permission, ...
22
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 ...
22
The main advantage of a refresh token is that it is easier to detect if it is compromised.
Consider these two scenarios:
A single long-lasting auth token is used.
A short duration auth token is used, and a long-lasting refresh token periodically requests a new auth token once the previous one has expired.
In scenario 1, if the auth token is compromised it ...
21
Acceptably secure within the realm of what?
You have described the basic flow for all bearer tokens. They who bear the token have the power. You do have a condition where you check if the token has been revoked, but that will mean the token is valid until they expire or are revoked. This is fundamentally the same as checking if the user is valid in the ...
20
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
@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
...
17
You are correct. App secret should be secret and should not be easily obtained by reverse engineering your client code.
Facebook uses OAuth so everything I say here also applies to all the applications that use OAuth to authorize and authenticate. The app secret authenticates your client to facebook. Just like a username/password authenticates a user to a ...
17
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. ...
17
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 ...
16
It could be that the access token might end up being used around the application over plain HTTP connections. So if an attacker sniffed it, they would only have short term access. This is what used to happen on the web as standard. Login was over HTTPS if you were lucky, and the rest of your session was over plain HTTP, transmitting the session ID in ...
15
To answer your questions:
1) How do you handle a situation with a compromised token secret which is shared between a client and the server?
Add an expiry date to your token. Make sure the token cannot be used after the expiry time. But this doesn't prevent unauthorized access within the token's expiry period.
So, to overcome this problem you can embed ...
15
1.What is the difference between authentication and authorization?
Authentication is the process, by which a server checks if a user is indeed the user that it claims to be. This is usually done, when the user gives the username and a password, while the server checks these credentials (username, password) with those stored in its database, when the first ...
14
I will simplify this problem. Cross-Site Request Forgery and Clikjacking attacks are useful because it can force a victim's browser into performing actions against their will.
The mention of 10.12. Cross-Site Request Forgery and 10.13. Clickjacking in the OAuth v2 RFC have fundamentally the same concern. If an attacker can force a victim's browser into ...
14
In OAuth, or any other protocol where the token can be opaque or transparent, the benefits and risks swing based on what your desired result is:
If you want the client to be able to parse the access token, you need the token to be transparent.
If you don't want the client to be able to parse the access token, you need the token to be opaque.
Indeed, this ...
13
Well, it depends...
OAuth is a protocol for creating a session. OAuth bearer tokens are transmitted by the client using the Authentication: Bearer HTTP header. This is just a cryptographic nonce that is transmitted via an http header element, which in effect is (almost) identical to the cookie http header element.
How does it differ? Well, the rules ...
13
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 ...
13
1. Where to authenticate the user?
If it is a user who needs to authenticate, then you need something in your front-end. From your front-end, you can just do a POST to your back-end, with the user credentials. You verify the user credentials, and issue an accesstoken/refreshtoken pair in case the credentials are known. You will ALWAYS have to go via the ...
13
As explained by Jacco, a naive implementation of authentication on top of oauth2 has several vulnerabilities, the most common of which is CSRF.
Given there's a perfectly good authentication protocol available without all this pitfalls, it's not a good idea to roll your own.
OTOH, there's a lot to learn by doing it and understanding and fixing these issues.
...
Only top voted, non community-wiki answers of a minimum length are eligible
