167
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 ...
80
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 ...
79
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 ...
71
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.
...
57
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 ...
49
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 ...
38
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 ...
32
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....
30
I like the idea, but I too have many questions left open. Please do not see this as any form of bashing, because I wrote it trying to apply my authentication experience to this new scheme.
I am concerned about (in no particular order) :
Unauthorized use of the private key
Rich client support (Outlook, Notes, etc.)
Using from multiple computers
Private key ...
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 ...
26
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 ...
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, ...
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
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 ...
19
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-...
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. ...
16
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 ...
16
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 ...
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
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
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 ...
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 ...
12
Stack exchange also has a detailed comparison of BrowserId and WebID. As argued there BrowserId is very close to WebID (a W3C Incubator Group at the W3C).
Here are some points that need to be made in defence of both protocols usually as they are very different from how public key cryptography is usually done.
Unauthorized script use of key. Agree that ...
12
As others have stated, this is not a new idea. Eran Hammer (one of the creators of the Oauth 1.0 spec, who resigned from the Oauth 2.0 committe) wrote a good synopsis of the vulnerability, almost 3 years ago. His description didn't get a fancy logo or any sensational media coverage.
http://hueniverse.com/2011/06/21/oauth-2-0-redirection-uri-validation/
12
Firstly, and to be very clear, OAuth 2 is not an authentication protocol. If you wish to know the identity of the user, there are other protocols designed to solve this problem, such as OpenID Connect. If you intend to use OAuth 2 for the purpose of authorizing access to your protected resources, continue reading.
To answer your direct question: you appear ...
12
I've been thinking about this and may have come up with an answer that will work for us, though I can't say whether it would work for you.
In our environment, the main reason we might need to use access tokens is to operate on behalf of a user after some automated or backend process is complete, or on a schedule. In such a scenario we can't simply ask the ...
Only top voted, non community-wiki answers of a minimum length are eligible
