Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

Can they be used together? ....or are they two separate protocols that may or may not be useful depending on the context?

The reason I ask is because I'm trying to implement the following:

  1. User "Bob" goes to a Client implemented as a User-Agent only application.
  2. The protected resources are controlled by the same domain as the authentication/authorization server, but they are on different subdomains. However, no session is found in the cookies, so...
  3. Bob clicks "login," and gets redirected to authorization/authentication server using something like the following:

    GET https://accounts.example.com/authorize?response_type=token&client_id=123&redirect_uri=http://original.example.com&scope=openid profile token custom
    
  4. Bob is given a list of options to choose from to authenticate, i.e., "example, google, twitter," etc. which leads to his authentication at example.com, which in turn is used for his authorization for a specific API hosted by example.com.

Should I be using OpenID Connect, OpenID 2.0, both? What? This is my first time implementing any of them. I'm only asking about the authentication part of this. I'm just trying to get Bob authenticated so that I can move on to issuing the token to the client.

share|improve this question

2 Answers 2

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. In your case, you apparently want to authenticate users with "Google, Twitter,...": you want Google (or Twitter) to tell you who the user is, but not what the user should be allowed to do; you want these external providers for authentication, not authorization.

Another way to see it is the following: a user connects to your server S. Server S offers some "services", i.e. will do "things" when asked for; however, it won't accept to do the same things for everybody. Let's assume that you found it fit to give control of what S may do or not for each user to another system which we will call R. R may or may not be the same computer as S, but let's think generically and assume that R is distinct from S. From the point of view of S, the needed information is in scope of authorization: S wants to know whether the call is to be granted or not. So there will be some authorization protocol going on between S and R. Possibly, S and R won't talk directly to each other, but only through messages ("tickets") which are transported by the client; that's a technical detail.

However, to decide whether a given request to S should be allowed or not, the authorization server R must know who is sending the request, because the answer depends on the user's identity. Therefore, R will need to authenticate the user; or, more generically, to talk to an authentication server T. T is responsible for making sure that the user is indeed who he claims to be. An authentication protocol then occurs between R and T.

In your example, R is your authorization server, while T is Google/Twitter. You would use OpenID between R and T, and OAuth between S and R.

OpenID Connect is when S wants to do some authentication as well; S then uses R (who "speaks OAuth") and infers that if R allows the request, then R must have done some sort of authentication of the user; so S decides that the user is indeed who he claims to be, since it (implicitly) convinced R.

share|improve this answer

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 enables Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an interoperable and REST-like manner. OpenID Connect Core 1.0 - draft 17

Things is, OpenID connect provides you a "standard" way to obtains user identity. If you use OAuth and the API, you should adapt your request for each ressources, which may not always provide the same information or may change over the time. And conceptually, you use OAuth to be allowed to use an API, not to authenticate an user.

As background, the OAuth 2.0 Authorization Framework [RFC6749] and OAuth 2.0 Bearer Token Usage [RFC6750] specifications provide a general framework for third-party applications to obtain and use limited access to HTTP resources. They define mechanisms to obtain and use Access Tokens to access resources but do not define standard methods to provide identity information. Notably, without profiling OAuth 2.0, it is incapable of providing information about the authentication of an End-User. OpenID Connect Core 1.0 - draft 17

Note that, OpenID connect provides an id_token with some information about the user. But if you want the whole set of information, you still need the access_token to request the the OpenID provider to get the userinfo (which confuse me the first time I see it). See 5.3.1. userinfo request in the draft

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.