CODEWITHSUNDEEP
web-servicesrestsymfonyoauthoauth-2.0
brainbowler
brainbowler

Reputation: 675

OAuth 2.0 scopes as service identifiers for centralized authorization?

I am about to write a central service for authentication AND authorization in our company, let's call it C-AAA.

This central service is holding all user credentials. It is also equipped with a web-based user interface where administrators may assign access rights for different services (i.e. web applications) to specific users. These applications should now use a standardized method to ask C-AAA whether a user should be provided access or not.

The first thought which came into my mind was to use OAuth 2.0 as this allows us to easily provide the auth interface also to third party applications, mobile apps and so on.

The process I imagine is as follows:

  1. A secured web application ("SecApp") is called by a user.
  2. SecApp checks for an existing valid session (within the application).
  3. If no session exists already, it calls C-AAA using a client secret and client id as OAuth suggests. Additionally, the applications sets a scope for the request, being her own name 'secapp'. If client id and secret are correct, an authentication code is returned.
  4. Using the auth code, the user is redirected to the login on C-AAA.
  5. The user provides his/her credentials to C-AAA.
  6. C-AAA verifies them AND checks whether the requested scope corresponds with the roles associated with the user. ("secapp.user" and "secapp.admin" might be defined as valid permissions in this case.)
  7. Only if both conditions are true, the user is authorized and an access token is generated.
  8. The access token is returned to the SecApp application.
  9. Information about the user's personal data and application permissions (user/admin) is fetched from the C-AAA.
  10. The user information is stored in a session variable within the SecApp application and access is granted according to the returned roles.

The OAuth specification does not say too much about the use of scopes. Therefore, I am asking:

Is this a legitimate use of the OAuth 2.0 standard? If not, which method would you recommend in my case? (I'd really like not to reinvent the wheel and therefore stick with standards.)

Side note: C-AAA is implemented with Symfony2, using FOSUserBundle and FOSOAuthServerBundle.

Thanks in advance for your answers!

Upvotes: 1

Views: 670

Answers (2)

divyanshm
divyanshm

Reputation: 6800

This looks like a good use case for OAuth.
Firstly, The C-AAA app is supposed to store not just the credentials but also the scopes.

Now looking at the points that you have mentioned, I would want to suggest one change in the flow.

In step 3 -> When user hits the SecureApp endpoint, and no active session is open, the user must log in and provide credentials.

Logging in should be a feature of C-AAA central identity provider. So, user is redirected from SecureApp to C-AAA portal where he logs in and the client gets an access token in return when the login attempt is successful. This login and access token generation is all happening between the client and the C-AAA module. {Notice how a popup opens up when we do a login via Facebook}
So, once logged in C-AAA returns a token to the client (THIS DOES NOT CONTAIN THE CLIENT SECRET). This is pretty much like a SSO. The access token with the client contains info about the user and the allowed Scope as encrypted data.

The client now hits any endpoint in your organisation with this access token (till the token is valid). The API's internally call C-AAA to authenticate the user and check if he has access to the requested operation.

The advantage of this approach is that you can with time create more endpoints within your organization and make sure they authenticate the access token provided with the C-AAA module.

I remember writing a more detailed answer here - How would an efficient OAuth2.0 server / provider work?

Upvotes: 1

rolebi
rolebi

Reputation: 1181

I think that it is not the role of the C-AAA to decide whether the user can access the application based on his 'role'.

The scope parameter is used to indicate a list of permissions, that are requested by the client

The applications must required (that is the role of the scope parameter) access to the 'role' of the user and, after validation of the C-AAA credentials, use this information to decide if it allows the creation of the session at the application level or deny access to the user.

Upvotes: 0

Related Questions