OAuth2 implementation approach

0
votes

I'd like to implement an OAuth2 server (technique doesn't really matter). I have a question about an approach:

Suppose I have an OAuth2 server which provides access_tokens and refresh_tokens. My users are going to login via an OAuth2 provider like Google and Facebook. When the external provider gives an OK sign to my application, I want to store the users name and email. After that, the user is known to my application and my server provides an access_token and a refresh_token. That gives my application actually two roles:

  • OAuth2 server (storing the users' information and provide access based on the aforementioned tokens).
  • OAuth2 client (getting authorization based on an external provider).

Does this comply with the RFC 6749 spec? Per my understanding, an OAuth2 server also have access the users' password and username, but I don't like to store sensitive information about the user. Or is this a common approach?

1
authenticationoauth-2.0

1 Answers

1
votes

In a narrow sense, an OAuth server is a server for authorization. In a broad sense, people unconsciously expect the following three roles when they refer to an OAuth server.

  1. Authentication
  2. Authorization
  3. Resource Management

Using an external provider (such as Google and Facebook) for login means that you delegate authentication to the external provider. Note that RFC 6749 says that authentication of resource owners (= end users) is beyond the scope (see 3.1. Authorization Endpoint).

Providing access based on access tokens is categorized as resource management. RFC 6750 should be referred to instead of RFC 6749. Resource management is also beyond the scope of RFC 6749.

However, behaving as an OAuth 2.0 client for the external server does not have any special meaning for client applications of YOUR server.

So, using an external provider does not necessarily mean that your server is an OAuth server. In other words, your server may behave as it likes without caring about RFC 6749 after the end-user authentication performed by an external server.

What makes people confused are some solutions that use external OAuth servers for "authentication" (not for "authorization"). Examples are OmniAuth and Auth0. Authentication is beyond the scope of RFC 6749, but the flow at the authorization endpoint includes end-user authentication as a step. Solutions such as OmniAuth use the authentication step for the different purpose. However, for the purpose of "authentication", OpenID Connect should be used.

If you don't like to store sensitive information about users, using an external OpenID Provider is an approach. Google, Facebook and other big names are now OpenID Connect server. Note that an OpenID Connect server is an OAuth 2.0 server at the same time, so you can use it as an OAuth 2.0 server. Stormpath is also worth checking. It offers "The User Management API".

If you want, it is also possible to delegate management of (a) access/refresh tokens, (b) meta data of client applications and (c) metadata of your services to an external pure "authorization" server. Authlete is an example. Authlete Defenitive Guide and the blog contain detailed generic information about OAuth 2.0 and OpenID Connect from an implementor's viewpoint.