You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the SSO scenario, we store a set of tokens, (access_token and optionally refresh_tokens, and id_token) against the original provider, and the user.
The primary use case here is for auto-registration of the user (identified by email).
The secondary use case here is to (later) access those original systems using those tokens.
Those tokens can be fetched, and refreshed, and used (by that user only).
Further, users are uniquely defined (in the EndUser subdomain) by their username, which is their email address that they were registered with. which is owned by the UserProfie subdomain. No two EndUser can be registered with the same email address.
However, what we don't support yet, is the ability to store multiple sets of tokens (access_token) against multiple providers for the same user (each with possibly a different email address).
So, if we want to access another system for this EndUser we are unable to do so presently.
Conceptually, what we need to do, is have that user authenticate against that other provider (without auto-registrating them), and to store those auth tokens against the users account.
The email they use to do that SSO authentication flow needs to be stored with their auth tokens, but it should not considered when detecting uniqueness when registering new EndUser.
In other words, it is possible for a user to SSO auto-register an EndUser against Microsoft with the email address [email protected] and to access to all Microsoft systems. Then later, for this specific EndUser to SSO authenticate against Google, with an email address [email protected] and that OG EndUser to have access to both systems with both sets of tokens.
Then it should be possible to explicitly register a new user on the platform using SSO to Google using the same email address [email protected] and have access to all Google systems as a different EndUser. This is possible.
What
The text was updated successfully, but these errors were encountered:
Currently, we support authentication with:
In the SSO scenario, we store a set of tokens, (
access_token
and optionallyrefresh_tokens
, andid_token
) against the original provider, and the user.The primary use case here is for auto-registration of the user (identified by email).
The secondary use case here is to (later) access those original systems using those tokens.
Those tokens can be fetched, and refreshed, and used (by that user only).
Further, users are uniquely defined (in the
EndUser
subdomain) by their username, which is their email address that they were registered with. which is owned by theUserProfie
subdomain. No twoEndUser
can be registered with the same email address.However, what we don't support yet, is the ability to store multiple sets of tokens (
access_token
) against multiple providers for the same user (each with possibly a different email address).So, if we want to access another system for this
EndUser
we are unable to do so presently.Conceptually, what we need to do, is have that user authenticate against that other provider (without auto-registrating them), and to store those auth tokens against the users account.
The email they use to do that SSO authentication flow needs to be stored with their auth tokens, but it should not considered when detecting uniqueness when registering new
EndUser
.In other words, it is possible for a user to SSO auto-register an
EndUser
against Microsoft with the email address[email protected]
and to access to all Microsoft systems. Then later, for this specificEndUser
to SSO authenticate against Google, with an email address[email protected]
and that OGEndUser
to have access to both systems with both sets of tokens.Then it should be possible to explicitly register a new user on the platform using SSO to Google using the same email address
[email protected]
and have access to all Google systems as a differentEndUser
. This is possible.What
The text was updated successfully, but these errors were encountered: