CODEWITHSUNDEEP
cookiesoauth-2.0refresh-token
Travis Pettry
Travis Pettry

Reputation: 1352

OAuth Refresh Token Architecture

I have multiple web applications that I want to use our oauth provider for. All web applications live on different domains. For example, a.com b.com and c.com.

My oauth provider when the token end point is accessed returns a refresh token via a http only cookie. This is fine in theory, but the browser will not accept the cookie due to it being a cross domain cookie. (I have tried just about everyhting to allow this. See below.)

Cookie Settings
Same Site: none
secure: true
domain: null
http only: true

I have tried setting the cors of the web app to allow the auth api end point

CORS settings:
WithOrigins: "the url of the api"
WithMethods : "GET, POST"
WithHeaders: "Content-Type, *"
AllowCredentials : true

How can my my oauth provider send back a refresh token that I can securely store on the client?

Upvotes: 0

Views: 666

Answers (1)

Gary Archer
Gary Archer

Reputation: 29263

The usual solution is that the OAuth Provider (Authorization Server) issues tokens to your back end, then applications issue their own first party cookies for the browser, in the Same Site as the web origin and therefore are not impacted by browser cross domain cookie restrictions.

The easiest to manage option can be to store tokens in AES256 encrypted HTTP Only SameSite=strict cookies, whose decryption key is only known to the server.

TOKEN HANDLER PATTERN

One interesting variation in this is for an API to issue secure cookies used by a Single Page Application. This involves hosting that uses related domains. Cookies issued by the API are then in the Same Site as the web origin and not cross domain:

See this Curity Code Example for further info on an SPA solution. If you are using a website technology stack, you will not be using an API but the same cookie principles will apply.

Upvotes: 1

Related Questions