1

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!

Community
  • 1
  • 1
brainbowler
  • 667
  • 5
  • 17

2 Answers2

1

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?

Community
  • 1
  • 1
divyanshm
  • 6,600
  • 7
  • 43
  • 72
  • 1
    "The API's internally call C-AAA to authenticate the user and check if he has access to the requested operation": I would say the API validates the token (by calling C-AAA, but this is just one option), _and accepts/denies the request based on the user-id and scope of the token_ (it shouldn't need the C-AAA for that). – Jasper N. Brouwer Jul 27 '14 at 18:38
  • 1
    All I meant was for a single module for A and A. Something that any REST API can hook to. – divyanshm Jul 28 '14 at 05:10
  • Thanks @divyanshm, your comments are very helpful. Jasper: For me, it is important that C-AAA is the only part of the system holding the user data entities and the coding effort on the side of the connected applications is kept to a minimum. (I want to re-use the same simplified code snippet with only the scope and possible additional application roles as parameters to check the user's permissions on the side of the applications.) Therefore, I will try to implement divyanshm's approach. – brainbowler Jul 28 '14 at 07:43
0

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.

rolebi
  • 1,181
  • 9
  • 13