0

I've read through RFC6749 for OAuth 2.0 as well as quite a few SO questions and blog posts but I'm still unclear on how to implement some of the things.

Currently, users log in through a form on a web page and use the application which makes database calls to fetch and manipulate resources. The goal is to abstract out the resources from the application.

In the context of OAuth 2.0, I've identified that:

  • The users are resource owners
  • My web application is the client, specifically a confidential client
  • My API is the resource server

I also understand that OAuth 2.0 works by authorization grants and access tokens (at the minimum). I'd like to support the password and client credentials grant types in my authorization server. Lets also assume that my web application is the only authorized application to access the API.

Questions regarding implementation with resource owner authorization grant type:

  1. Does every user receive their own access token? I'm assuming yes because I need to distinguish between different users for additional purposes (e.g. authorization)
  2. Can a user receive more than one access token? (e.g. if they log in to the application at more than 1 user-agent/computer)
  3. What do I send in the Authorization HTTP header to the authorization server? (Remember I only have one client)
  4. How do I get the identity of the user from the access token? (e.g. user ID/username)
  5. Is it safe to store the access token and refresh token in $_SESSION in the web application?
Community
  • 1
  • 1
rink.attendant.6
  • 44,500
  • 61
  • 101
  • 156
  • When you say "resource owner authorization grant type" do you mean the Authorization Code grant type or the Resource Owner Password Credentials grant type? Also note that OAuth 2.0 does not authenticate users, see: http://oauth.net/articles/authentication/ – Hans Z. May 06 '15 at 21:50
  • I mean resource owner password credentials grant type. And authentication of users is done internally, not through OAuth 2 I believe. – rink.attendant.6 May 06 '15 at 21:56

1 Answers1

0

My overall comment would be that you should not use the Resource Owner Password Credentials grant to achieve what you want but the Authorization Code grant. That would allow you to upgrade your means of authentication independently of the Clients (applications) and achieve SSO as well.

  1. It is not the user (Resource Owner) that receives the access token, but the Client (your web application). Your Client receives an access token for each user when using the Resource Owner Password grant or the Authorization Code grant. When using the Client Credentials grant it would be most logical to obtain an access token to operate in a privileged mode for all users with the same token.

  2. Typically not because in OAuth 2.0, users do not log in to the application. Except when using the Resource Owner Password Credentials flow, they do. In that case the application should notice that there's an existing access token for that user and it would not request a new one.

  3. That seems to confuse usage of the access token in an Authorization header against the Resource Server with authenticating the Client or the Resource Owner against the Authorization Server. In the latter cases there's not requirement for HTTP Basic Authentication, that's just one of the options for Client/Resource Owner authentication.

  4. If you want to authenticate users, you need to apply OpenID Connect, a user authentication protocol built on top of OAuth 2.0. See also the previous link in Q2. If you want information about the user who gave the Client the access token at some point earlier, then you could use the access token against an API that would provide you that information or you could embed it in the access token (e.g. in a JWT access token).

  5. It is a common way of doing things which is as secure as your PHP installation is, see: Security of $_SESSION array

Community
  • 1
  • 1
Hans Z.
  • 50,496
  • 12
  • 102
  • 115
  • Thanks for the response. Currently there are two types of users that log in to the protected areas of the system: staff and students. Some of the apps in the organization for students are already SSO and there are plans to move that part of our application to SSO sometime next year, so authorization code will have to be implemented by then. However for the staff there is no SSO mechanism so I guess that will be done using Resource Owner Password Credentials. – rink.attendant.6 May 07 '15 at 00:37