Consider a use-case in which a single page application using an OAuth identity flow has to use one of many possible identity providers, as determined by what user is logged in. More specifically, I log in using my credentials for Company A, and the app directs the client app to use Okta, and if I log out and log in again using different credentials for a different company, Google is used as the auth provider (the provider is associated to a specific company/user by info stored server-side).

The client-side app would be mostly agnostic to which auth provider is being used as long as it has a token to hit the main app's backend API. What it would need to know though is what URL to hit to initially log in, and where to occasionally obtain a refreshed token (where it would also pass an HTTP-only session cookie that was issued on log in).

While this information could be passed back to the client app on log in, the question is, where should it be stored? Ideally there is no stateful information stored locally aside from the HTTP-only session cookie. But if a session is in play, upon initialization the Javascript in the client app would need to at least know which URL to hit to try for a new token.

The only thing I can think of is that the log in step also sets another JS-accessible cookie, or uses localstorage, that simply stores the provider name and/or refresh endpoint. I don't know if there is anything particularly insecure about this approach, but I thought I'd see if anyone had any better ideas on how to handle this use case?

  • Why not do something like what Google/Microsoft accounts does right now? You enter the login ID in the client and based on your ID, you are directed to the corresponding login portal.
    – Limit
    Feb 21 at 5:30
  • That could definitely work for the initial sign in. I just wonder how Google/Microsoft handle refresh tokens. Like if I came back later or opened a new tab, the app would have to know what kind of cookie to look for (or what SDK to use) in order to determine if there's an active session. Can't think of a better way around that than either storing the provider's details, or the user's ID (which could then go to an endpoint that just returns the provider info).
    – Dan
    Feb 21 at 18:29
  • I don't follow, why would it be hard for the app to know what kind of cookie to look for? Can it not be configured in code? And add that cookie when you redirect to the login portal?
    – Limit
    Feb 22 at 1:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.