Does Auth0 provide a mechanism to limit potential cross-client access. Let me give you an example:
we have 2 authorization code clients, one is a client used in one front-end product, the other client is used in another front-end product
we have a user who has access to the first product (they can login through the client app, get a token and use that token to call APIs)
is there any mechanism for blocking the user from being able to login through the other client application? (that application uses the same set of APIs under the hood).
I understand that the front-end can be considered public, and the token in one case and the other would give access to same set of resources. However I still am interested to having this sort of soft limitation - if it exists.
The most straight forward way to achieve your described case would be implementing a Post-Login Action. In our documentation about the Login Trigger, the first mentioned example provides a snippet of code used to deny access to a user who is attempting to access an application:
exports.onExecutePostLogin = async (event, api) => {
if (event.user.email && event.user.email.endsWith("@example.com") && event.client.name === "My SPA") {
api.access.deny(`Access to ${event.client.name} is not allowed.`);
}
};
Additionally you could also set up a flag in the app_metadata after a user’s first login and check against it to provide access to an application or not.
An alternative approach would also be creating an Auth0 Organization, add your Application B to it and allow access to users only if they are a part of that Organization.
Hi @remus.ivan thanks a lot for your response. Is it possible to store a userId to clientIds mapping somewhere (or an external API) and use that to define whether that given user can get a token or not? Could it be done in the PostLogin action as well? Thanks!
To answer your question straight away, it’s a Yes.
This is exactly what i was referring to earlier, meaning that you can also set up an array of allowed clientIDs for each user inside app_metadata, since this type of metadata can not be modified by the user. This can also be accomplished using a PostLogin Action, as you are mentioning as well.