There have been discussions about either considering support for Pre User Registration / Post User Registration for Social / Enterprise connections, or having a different Trigger type specific for those.
But there isn’t an imminent plan to deliver this functionality.
Would you mind posting your specific use case? Which could serve as evidence for future ideating
There are plans to make it Cross-Trigger in the future, which would increase the coverage over other Triggers and Actions types.
Could you help us by posting your specific use case? It will be a source for future ideating
Currently, there is no way to control the passkey progressive enrollment from Extensibility like Actions or Custom Database Scripts.
Would you mind explaining your use case? Which would be helpful for our Product Team to ideate.
Actions Cache is expected to be used to share information that is relevant to all Actions unrelated to the user or the specific transaction, such information would be expected to be reused several times on multiple executions.
For example, an Access Token obtained on behalf of the Actions to authorize the interaction of those Actions with an external service.
Actions Transaction Metadata is expected to be used to share information between Actions on the same execution and transaction, which is implicitly related to the same user.
For example, an Access Token obtained on behalf of the user to authorize the interaction of the executing Actions with an external service on behalf of that user, which will be cleared after the current transaction is finished.
Both the cache and transaction metadata can help improve the performance by not having to retrieve or calculate the same data when present in the storage, but the scope of access and meaning of the information is different between them.
The cache as the transaction metadata currently, is not accesible cross-trigger.
The cache has scenarios where values set may not be available, like after continuation of MFA challenge, redirects, and forms rendering, which also depend on how the infrastructure scales below the hood.
Useful Docs:
For performance and reliability of each Action it is important to:
Cache when possible to reduce the dependency on external services or extra processing.
Handling errors and using timeouts properly.
Reducing the complexity of the code minimum is always a plus.
Finishing the Actions early when conditions match.
Additionally, there are some patterns that can be applied, like:
const libraryM = require('libraryM');
exports.onExecutePostLogin = async (event, api) => {
libraryM.doSomething();
};
const subFunction = (paramt1, param2) => {
// code
};
exports.onExecutePostLogin = async (event, api) => {
subFunction(event.user.user_id, event.transaction?.metadata?.key);
};
const CONSTANT_N = 'constant_value';
let variableM = 'variable_initial_value';
exports.onExecutePostLogin = async (event, api) => {
console.log(CONSTANT_N, variableM);
};
const LibraryM = require('libraryM');
let variableM;
const getVariableM = (api_key) => {
if (variableM === undefined) {
variableM = new LibraryM(api_key);
}
return variableM;
};
exports.onExecutePostLogin = async (event, api) => {
const vM = getVariableM(event.secrets.API_KEY);
vM.doSomething();
};
For large numbers of Actions across different Tenants, it’s important to:
Useful Docs:
Sample codes are not production ready, they are just looking forward to clarifying a concept.
I will follow up on these questions with more time to be able to answer them.
Currently, Actions don’t have a way to alter the organization related journey, meaning that the api object for Post Login Actions doesn’t have an organization interface to bet able to force that organization selection. That could probably be debated as feedback for future improvement, which should also consider if Post Login is the right and specific place to provide that functionality.
The best option available is Prompt for Credentials, because it provides a way to the user to choose.
Presenting a Form would require using Management API to retrieve the organizations for the user to be able to list them so he can choose. That can create problems with Rate Limits and potential failure on the journey to authenticate the user at the point where the API is invoked.
Redirecting to an external site would have similar issues regarding Management API.
Both would need to redirect eventually to /authorize again with the organization ID to pre select the organization, as there isn’t a way to force it from within the Forms or Actions. This would leave the previous authentication process to timeout, which is not great, and use more times the /authorize.
If users already know they belong to an organization, maybe an alternative is to provide a different entry point for them at the application, probably a separate client only allowing organization members. A separate entry point for those that are individuals. But this is a different implementation.
Would you mind proving more specifics about your use case? I will share this with other Product Managers to see if there is an opportunity for improvement in the future.
Thank you for the response!
We are considering using the built in Organizations for B2B ecommerce users on our site. So good to know that actions is not the way to go and that we might have to continue our own way of doing organizations or find another way of getting around this in our application.
To give some more details of our problem:
We have users that are only using other services and don’t use our ecommerce functionality. This means these other users might not yet have a connection to our current own equivalent of Auth0s organizations, with users connected to a customer number matching customers in our ERP system, and therefor need to login using a personal account.
The issue in Auth0 lies in that the “Prompt for Credentials” Login Experience for both personal and organizational logins on the same client, allows users that have an organization affiliation to choose logging in as a personal account. If the users does this the would not get access to our sites ecommerce functionality.
So to not confuse our users into accidentally choosing to login as a personal account, and then us getting complaints of users not being able to use ecommerce functionality, we want to be able to avoid giving the user the option of choosing to login via a personal account, if they are actually part of an organization.
Please do forward this to you colleagues. Maybe this could be an improvement in the “Prompt for Credentials” Login Experience for clients. To add a version of the login prompt that only allows non-organization affiliated users the option of personal login, while then allowing org affiliated users to login only via an organization and being able to choose which one if they have many.
And again thanks for the response!
Thanks for the additional details @Bjojoh , I have given some feedback based on what was described for future ideating.
When a key/value pair is set in an Action using api.transaction.setMetadata(key, value), it becomes available immediately after in the same and subsequent Actions using event.transaction.metadata.key to access it.
When Redirects and Forms render continue the Action execution the transaction metadata is still available on current and subsequent Actions.
Examples:
Size limits can be found in the following documentation:
https://auth0.com/docs/customize/actions/limitations#transaction-metadata
Could you share what made this capability tricky to ship (I imagine many of us have had to implement creative solutions to work around this missing feature over the years) and how you envision it being used for multi-step flows?
We didn’t want to deliver a feature that just emulates what Rules provided for the parity gap sake, we wanted to deliver something that was more aligned with the current and future extensibility capabilities. Once that definition was clear, the feature was prioritized and delivered.
When we deliver Cross-trigger coverage, then it will become an even more powerful tool to enable creative solutions that will improve overall performance on those solutions if the Transaction Metadata is used wisely.
For example being able to define or retrieve information in a Custom Token Exchange Action, and then being able to reuse the value in Pre User Registration and/or Post Login Actions without having to retrieve the values again or use the user profile metadata as a bridge.
Soon, we will be publishing an NPM library with the Actions TypeScript definitions, which can improve the developer experience when developing Actions on external IDE/Code editors and enables developers to follow better practices when coding and implementing Unit Tests.
Yes, we are working on it in the second half of the year.
Yes, Actions Types (A.K.A. Actions NPM) will provide part of that, now the optional clarity may not be there, that depends on the context of the execution which is abstracted from the types, for that we are discussing documentation improvements, which may also affect the Actions Types as a way to communicate those details.
There are no imminent plans, the closest we have discussed is what I mentioned in a previous question: https://community.auth0.com/t/august-27-auth0-community-ask-me-anything-actions/190450/21?u=danilo.asissanchez
By Action Test Runner, do you mean the Test insider the Action Editor?
As mentioned there, please provide some feedback about your particular use case which can be used as evidence in the future.
I think this is related to a previous question you asked about Actions Types and optional properties. Note taken for a potential improvement in the future adding a set of testing templates based on use case with event object definitions narrowed to the particular test case.
Although there not a defined plan on adding the risk signals for refresh token exchange, we are doing some ideating about it and your feedback could be useful, if could post the specific use case details we would appreciate it!
It will depend on your implementation, if the operation you are trying to achieve is necessary for the authentication outcome and your application working correctly and securely, then you should use either api.access.deny or api.sessions.revoke, depending on the expected result after the failure.
In some other cases, the operation may not be required for the application to work properly or for securing the login, then in those cases you may be able to just catch the timeout error and continue the Actions execution.
Either case you should set a timeout and handle the error.
There hasn’t been any discussions about it, what is your specific use case? Having in mind that certain Triggers/Actions are executed synchronously and others asynchronously.
This is in our Rules/Actions parity gap list, we haven’t yet defined how we will solve it, but we are planning to solve it H1 next year. It may not be 1-to-1 with Rules as it will depend on what is best for the Actions architecture and future of Extensibility and other features depending on Extensibility.
TBD
TBD
TBD
TBD
TBD
TBD
Similar post: https://community.auth0.com/t/august-27-auth0-community-ask-me-anything-actions/190450/9?u=danilo.asissanchez
What’s your use case?
There are two Fingerprint integrations at Auth0 Marketplace:
There is a comprehensive 2-part Action integration that provides device fingerprinting capabilities including device recognition, risk-based security checks, bot detection, VPN detection, and adaptive MFA triggers based on suspect scores:
There is opportunity for something out of the box, but there isn’t anything planned. If you could provide feedback that would be helpful in the future.
The sweet spot may vary for each implementation, I think it’s important to have in mind:
The 20 Actions per Trigger limit, because if the model is early defined to separate by some criteria, then later in the implementation process that model may result in more than 20 Actions per Trigger to preserve consistency or a remodel when the limit is reached.
Separating is good, but have in mind that load the Actions and dependencies may take a minimum time which may create more latency when splitting in too many Actions.
Longer code could also impact the loading process, same as unnecessary Secrets and Dependencies.
The sweet spot is about balance for each implementation.
Anything exciting you’re able to share about the future direction of Actions or new features in the works?
Actions Transaction Metadata is an important feature, going Cross-Trigger will allow new use cases that were not possible before these features.
Actions Modules will improve the overall developer experience and at the same time help on performance and maintenance. It will also expand the usage Actions Types NPM library as additional tooling.