CODEWITHSUNDEEP
authenticationoauthpermissionsauthorizationopenid-connect
Lakin Lu
Lakin Lu

Reputation: 4996

What’s the difference between application permissions and oauth2 authorization?

Currently, we already have an application, it’s a front-end and back-end separated application, front-end is a web application (SPA), back-end is a web API.

For the application, we already have use register, user login, user role, role permissions, user check and permission check.

Now, we are integrating an external identity service (open id and Oatuh2), but I misunderstand the authentication and authorization for the external identity service

Question 1: Yes, I can use external identity service for login and get an access token, but after that, I still need to maintain the user in my application, since for business, I need to know who create the order, who operate it etc… so, then the user system what I do in my application, I still need to do, does it correct what I do?

Question 2: For authorization, I still need to maintain user role, role permission and permission check for myself in the application, if so, what the authorization for identity service (OAuth2) for? And what the difference between the OAuth2 authorization and permission module in my application?

Upvotes: 3

Views: 1565

Answers (1)

Kavindu Dodanduwa
Kavindu Dodanduwa

Reputation: 13059

First thing, OAuth 2.0 does not define how to handle permissions. It define a way to obtain access tokens. Access tokens are secrets that your API accept as access grants (ex:- Compare them to basic auth. header. Instead now you receive a token).

How to do the token validation ? You have two main options. You can do a token introspection (RFC7662) against token issuer (the identity service). The response will contain a payload, which may contain authenticated end user and token expiry details.

Alternatively, if access tokens come in JWT format (RFC7519), then your API can look for specific claims sent in JWT (you will do a JWT validation which include JWT signature validation). Claims should include end user as well as expiration details.

In either way, your permission logic can be invoked after extracting required information.

Regarding authentication, this is built with OpenID Connect and ID Token. Authentication will happen in client end (SPA as in your case). This is independent from API invocation.

Regarding permissions, users and role mappings. If you are using a built in user data storage, then you will need to do a user mapping between external identity service and internal storage. Otherwise there is no way to correlate user data you receive through tokens (as explained in first part of the answer) with inbuilt ones. This is something independent of OAuth 2.0 and OpenID Connect.

For example, if the user is not found in internal storage then you may assume that user to belong to a restricted user role. Also, you may add that user to your internal system at the first time you receive such data (when validating the token). Later, there can be a process to assign permissions for the user who got on boarded. Exact implementation details depends on your scenario though.

Upvotes: 5

Related Questions