0

I am a little confused on how the token is shared from the client to an AJAX script to the resource server in the oauth2 flow.

To explain the scenario I am trying to set up, I have

  • a client (http://localhost:3000)
  • a resource server (http://localhost:3001)
  • an authentication server (http://localhost:3002)

The client is a server that is communicating with a user in the browser. The client obtains the token from the authentication server through the use of the authorization flow, it then sets the token as a cookie which is shared with the user. This means that the user has the token, but now the client wants the page delivered to the user to make an AJAX request to the resource server for information.

Since the token is locked between the client and the user, and CORS forbids the sharing of cookies when 'Access-Control-Allow-Origin', '*' is set. How can the AJAX request obtain the token and send it to the resource server to be validated?

Or am I confusing the workflow/trying something impossible? Thanks in advance!

Improve this question
1
  • sounds like you need a single-sign on/multiple domain solution. I believe each domain will have it's own unique session token in that case, which means logging in and/or remembering a user for each as well. (but why does the user have to interact with the resource server? You could have the "client" server do that...)
    – pcalkins
    Oct 4, 2021 at 18:31

1 Answer 1

Reset to default
0

There are different solutions possible.

1. Allow CORS requests on authentication server

The purpose of the authentication server is namely to provide tokens for other servers. That's why it is normal to allow CORS requests on the authentication server. Thus you can implement any additional logic in your application, including requests to the authentication server. Browser will not block them as CORS violation. If you want to make sure that the application code does not see the password in the plain form, you may want to use PKCE. See details in RFC 7636.

2. Redirect, or implicit flow

CORS requests on authentication server are not allowed. You send request to the resource server. It sees that authentication toke is missing or is expired. Then it redirects your request to the authentication server. The authentication server requests credentials and, if they are valid, redirects request to the resources server, and adds a valid token to the URL. The resource server validates token and returns you the requested resource.

3. Cross-domain messaging

In such case you don't need to allow CORS requests on authentication server. One should be careful: The code that sends the token from the authentication server to the resource server part should not use broadcast (because the token can be stolen by the script from malicious domain). Instead, one should send the token to the resource script window/frame only.

Improve this answer
14
  • Thanks for your answer! #1 makes sense, but (I think) it shouldn't be an issue as the client server in this case already has the token. My fear is that by making the token in the page accessible with JavaScript, it could be compromised via an XSS attack, but I am not sure how else to pass the token to the resource server as the token is locked between the client and the user's page, and if the origin is set to * it will not allow for credential passing. PKCE is a good idea, I will implement it once I have a good way of submitting the token from the page to the resource server.
    – user134909
    Jan 7, 2021 at 19:46
  • @user134909: For the #2: When server receives a token in the URL, it can put it to a cookie. If you make this cookie HttpOnly, then no script, even your own, will be able to read this cookie.
    – mentallurg
    Jan 7, 2021 at 20:06
  • That makes sense, so the resource server is the one that sets the token for the session not the client? Any idea why a lot of the explanations use diagrams that make it seem like the client application directly processes the token like the following assets.digitalocean.com/articles/oauth/auth_code_flow.png ? Is it because the auth server and the resource server are normally on the same machine?
    – user134909
    Jan 7, 2021 at 20:14
  • @user134909: If redirection is used, then the client code has no chance to read the code from URL. This is an implicit flow. This flow is easier to implement. But it is vulnerable to attacks. That's why IETF does not recommend to use it, see chapter 2.1.2.. The diagram you refer does not use implicit flow. You can find more info about it at Microsoft or Auth0.
    – mentallurg
    Jan 7, 2021 at 21:23
  • Yes I didn't want to use the implicit flow, I am trying to figure out the authorization flow (I want to add in PKCE as well but I need to figure this out first). I used the Auth0 diagram initially and it was the source of confusion, as in the last step (9 and 10) it uses the token it got from the OAuth server and sends it to the resource server. So unless the resource server and the OAuth server are the same, this will fail because the Client (outside application) generated the cookie and sent it to the User (browser).
    – user134909
    Jan 12, 2021 at 4:54

You must log in to answer this question.

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