4

I am trying to understand how would an application which uses OAuth2 (OIDC) server implement access control to its own resources.
In this case, the application is both 'Client' and 'Resource server' in terms of OAuth2.

So, user, from the browser, accesses the application and is being redirected to OIDC server where he gets authenticated, after which OIDC server sends access_token and id_token to the application (not to the user's browser, suppose the application is 'confidential' client in terms of OAuth2).
I suppose this access_token could be issued with access rights to the application (now acting as a 'Resource server'), which could be used to control the access to the application's resources to the user. But how could user send this access_token to the application (acting as a 'Resource server') since the user didn't get in possession of this token (it get's shared only with the application)?

Is it possible that this access_token be used to create some sort of "access" session between the user's browser and the application, similar to how id_token is used to build authentication session in form of a cookie? Or, is the authentication session used to obtain access_token from OIDC server every time a user accesses a different resource in the application, user being unaware of this communication since it is not asked for giving consent?

Or am I getting this whole thing completely wrong?

My case: suppose we have one web application which has backend and frontend, but frontend NOT being implemented as an SPA (in which case it would act as a 'Client'). The token is still shared between backend and AS (not going through the browser). How does my application control access to its resources? For example, the user is able to see the home page, but not an admin portal?

Please don't base your responses on my concrete use case, try to answer in general.

Improve this question

1 Answer 1

Reset to default
3

I believable your application have an architecture similar what I have show by below image,

enter image description here

Application have front end which runs in the browser and have a back-end. Authorization server is externalised (out of application's boundary). Hence your app have a back-end you can make application a confidential client. The login to application happens through OIDC flow. Browser redirect user to login page of authorization server. He/she provide credentials, server sends back an authorization code and this is passed to back-end which allows back-end to make the token request.

One option I see here is to create an authenticated session between browser and resource server. The green connection in my diagram stands for this session. This session being authenticate means that it is bound to access token. Session timeout is defined by access token expiration. This will require some logic from front end as well resource server end.

Another option is to pass access token to front end. With this, you does not require to maintain a session but front end requires to protect access token and send it with every request make to the back-end. So the green connection line now stands for bearer token trust connection (refer RFC6750 to see the standard way to transmit access token over headers)

Regarding access rights (consents), this will depend solely on context of your application. If you want OIDC to externalise user logins, user directories and authentication mechanisms, then I don't see the requirement to worry much about this. What you need an access token (and ID token).

Improve this answer
7
  • When you say that session is being authenticated and it is bound to access token, what do you mean, how do access and id tokens flow between application? As I understand id token is issued in order to prove to the application that this user is who he presents he is and allows backend application to create a session (in form of a cookie for example) between itself and browser.
    – Mike
    Jul 27, 2018 at 8:16
  • Passing access token to front end is not my use case, as I have pointed out in the title. Passing access token to the front end would mean that frontend application (Angular e.g) is 'Client' and backend application is 'Resource Server' in terms of OAuth2, but I am asking about scenario where 'Client' and 'RS' roles are played by a single application.
    – Mike
    Jul 27, 2018 at 8:25
  • My case: suppose we have one web application which has backend and frontend, but frontend not being implemented as an SPA (in which case it would act as a 'Client'). Token is still shared between backend and AS (not going through the browser). How does my application control access to it's resources. For example, user is able to see home page, but not an admin portal? I suppose backend has to pull this accessing information (roles if you want) from somewhere, and I think it does this from access token. I know how this could work, I just wanted to get confirmation if my thoughts are valid.
    – Mike
    Jul 27, 2018 at 8:31
  • client and RS being the same, so what is your front end and how you manage a state between front end and back end ? How to control the user seeing admin portal or not ? To do all this either you must maintain http session with browser or use a token. In case of a session, that must correlate to access token/id token. And ID token is not kept in cookie. it is to be consumed by client.
    – Kavindu Dodanduwa
    Jul 27, 2018 at 9:17
  • I think you didn't understand my questions. To answer your own question, my frontend would be static .html files served by my backend. The difference between this case and the case where you have an SPA is that this way token is not shared with the end user (using .html pages from the browser). So the backend is the one to exchange the authorization code for token, not SPA i.e. user's browser.
    – Mike
    Jul 27, 2018 at 9:48

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .