What SSO solution can be used that doesn't require a prompt from the user, and doesn't rely on fixed redirect URIs?

Question

I'm looking for a SSO solution that meets the following requirements:

• User accounts are stored on Site A (running on Django)
• Site A also provides API
• Site B needs to make authenticated & authorized API calls to Site A
• Users already logged into Site A should not have to enter credentials again

Also, a weird requirement is that we cannot "trust" Site B based on its domain name alone (the web app runs containerized on a 3rd-party service, which generates the app's domain randomly -- though we can store secrets on the container if needed).

I've looked into OAuth2, however it seems that requires a redirect_uri to be configured for the app (Site B) on the auth server (Site A). Unfortunately the domain for the app is dynamically generated on a per-user basis, so there's no way to know URI to supply ahead of time (unless I build some fancy workaround where the app container "registers" itself with the auth server on startup).

I thought of rolling my own token-based authentication system, however, I didn't want to re-invent the wheel if there was already a standard for doing just that. Is there anything out there that meets these requirements?

Answer 1

After reviewing my options, I decided to use a custom authentication flow similar to django-simple-sso. The authentication scheme is non-standard AFAIK, but it handles my use case.

If anyone is curious, the authentication flow goes like this:

1. A "client app" representing Site B is created on Site A, with a client_id and secret
2. Site B makes a back-end API request for a "request token", along with an Authorization header containing the client_id and client_secret.
3. This "request token" allows the Site B to send a user to /sso/auth on Site A, along with a next parameter. Site A will not redirect without a valid request token.
4. The /sso/auth page requires user session-based authentication. Once authenticated, the user is redirected to the next parameter with token added in the query string. The request token is also deleted at this point.
5. This auth token can now be used in the Authorize header for API calls.