Context
We have created a custom policy used when users are invited to our SPA application.
The policy does one time user initialization like creating records in our database by invoking the REST API capabilities. Everything here works as expected: The custom logic is executed and we get and id token back.
The problem starts when we are supposed to get an access token for a protected API when invoking the msal.js method
"acquireTokenSilent".
We now see, that the custom policy is executed again, the REST endpoint is once again executed and it's trying to create the user again.
Question
Isn't it possible to get an access token without executing all business logic defined in a custom policy?
I thought that getting an acccesstoken was completely separate from the policy, since we are already authenticated when we got the id token.
acquireTokenSilent in MSAL.js 1.x uses an iframe that runs through the login with prompt=none.
So in the case of implicit grant flow (which is used here), the answer is that it runs through the login flow every time the token is refreshed.
There are a couple choices here:
Make the API endpoint idempotent, i.e. allow calling it multiple times (but ignore the request if the user already exists)
Set a claim on the user that is stored in session state (SSO) and skip the REST API orchestration step if that claim has a value (or you can use the objectIdFromSession claim, which I think is there in the starter template)
The first option is sort of the simplest, and I assume you've already made it like that since it would be called again also when the user logs out and logs back in.
It might result in a lot of requests to that API though.
To avoid that, you could use the newUser claim or set an extension property on the user after the API call.
When calling acquireTokenSilent(), pass in a new authority for a normal Sign In policy. That Sign In policy needs to have session management (SM-AAD) and the same SM-AAD SM technical profile must be present in a technical profile within your invite policy, such that the user can get SSO via the Sign In policy after using the Invite policy.
Related
We have two custom policies written for our application - verify_email and signup_sign_in policies. We send a welcome email out (we do not use otp to verify email during sign up) to user with a link to the verify_email custom policy. The link contains a id_token hint signed by our certificate and the verify_email grabs the user principal from the id_token, gets the user from AAD, update the email_verified custom attribute then redirects the user to the application. This is a seamless process that doesn't show any UI to the user. The application will not recognize the tokens bec the tokens came from the verify_email policy so it will redirect the user to the sign_up_sign_in policy in adb2c and adb2c will see the current user session created by the verify_email policy and will redirect the user back to application with the claims needed without requiring the user to explicitly login.
What I have been seeing is half of the time, the sign_up_sign_in policy will not get the latest value of the email_verified claim that was recently updated. It seems like there is a delay that when you write the claim to azure ad, then read it sometimes what you get is the old value. Is there something that can be done regarding this lag to make sure I get the proper value all the time? Thanks in advance.
This is due to replication delay in the regionally replicated DC infrastructure. There is nothing you can do to influence this delay. You need to consider this as part of your workflows/design - eg, sign the user in using the id token hint journey, don’t ask the user to login again instantly. In this journey you’ll have all the up to date claims.
I'm using authentication code mechanism through Docusign's API for integration and works as expected.
Have a question regarding the documentation about implementation best practises, described in this page
Questions are related to the diagram at the end:
Question1
In Get the user's account ID, base URL and name (1st square) how do you recommend fetching the user/account information as before consent we don't know who is giving consent?
If it is related to users that may have given consent before, is it even necessary? If tokens already exist for the user, what is the purpose of verifying this scenario?
In the documentation it seems this is reinforced further with what is stated next:
How will we know what is the account/user information before the user gives consent?
Question2 (Similar to above)
In Collect the account ID (GUID) and name of the user, when no access token is found, I'm assuming we should redirect the user immediately so that the use gives consent again. Similar to the question above, in the diagram it indicates we should do this action "Collect account/user info" somehow before redirect for consent? We only know it afterwards as well, so is it needed?
It would be great if it would be possible to clarify the above!
As Inbar commented, that diagram needs some work. I'm sorry for the confusion.
Here's my recommendations for user present (Authorization Code and Implicit grant flows) and user absent (JWT grant flow).
All authorization flows
Determine if your users will typically use your application with a particular eSignature account or with any of their accounts. (It is common for customers to have access to more than one DocuSign eSignature account.)
If a particular account will be used, then provide an installation screen for your app where the admin can enter the account ID (use the guid format).
Your installation screen should also enable the installer to set
the DocuSign OAuth service provider, either production account.docusign.com or demo account-d.docusign.com
User present: Authorization Code and Implicit grant flows
Your app may or may not have its own login sequence for users. Your app needs a DocuSign access token for making API calls to DocuSign APIs.
When your user wants to authenticate with DocuSign:
Start the Authorization Code or Implicit grant flow.
When the flow is done, your app has an access token.
If the Authorization Code grant flow was used then you also have a refresh token.
Use the oauth/userinfo API call to obtain information about the user:
Their name and email
The eSignature accounts they have access too, and which of those accounts is the user's default account
For each account, the name of the account and the baseUrl for making API calls to the account.
If your app's users use a preferred account, then check that the user has access to the preferred account. Else, note the account id of the user's default account. (Also be prepared to handle the cases where there is either no userinfo response, no account or no default account for the user. These are infrequent DocuSign errors and can be fixed by contacting DocuSign Customer Support and referencing this article.
Use the expires_in OAuth response attribute to calculate your expires datetime. Then subtract 10 minutes so you have a buffer between the time you'll last use the access token and when it actually expires. You now have the last_use time.
Store the user's information, including the account id, base url for the account, access token, and last_use datetime.
If you have a refresh token, store it (and the user's information) in non-volatile storage.
When your application wants to make an API call
If you have a current access token for the user (last_use datetime is after the current datetime) then use it.
If the last_use time has passed, then use the refresh token if you have it. When refreshing the toke, you'll receive a new refresh token. Store it in non-volatile storage, overwriting the prior refresh token.
If no refresh token, then your app will need to ask the user to authenticate again.
Do not use oauth/userinfo again after either the token was refreshed or the user authenticated again. Keep and use the userinfo obtained after the person first logged in.
When your user wants to use a different account
Provide a "Switch accounts" feature to enable users to choose which of their accounts should be used. (Only applies if any account can be used with the application.)
User not-present: JWT grant
Your app's configuration screen will also need the user id in guid form. You can either store these values or look them up from DocuSign.
Decide whether a specific account is needed or not (see above).
Decide how the user will grant consent. See this video for more info.
First time your app needs an access token after a reboot
Use the JWT user grant to obtain an access token
As above, calculate the last_use datetime including a 10 minute buffer.
Use oauth/userinfo as above to determine if the user has access
the account or what the user's default account is. Also obtain the account's base_url.
Store the information.
Use the access token to make the API call.
Subsequent API calls
Check the last_use datetime. If it hasn't yet occurred then use the stored access token. If it has occured, then redo the JWT user grant flow but do not make another oauth/userinfo call--use the prior information.
Question 1 - You do not need to remember which user gave consent. That is not something you should do anyway, because users can revoke consent and then your information will be inaccurate. The system will ask for consent if needed (and if you ask for additional scopes it may be needed even if consent was given for example).
Question 2 - You should redirect immediately, whether consent is needed or not is unclear, but the user will either have to login, or just redirected if they have a cookie and consent is also based on their circumstances.
I'll consent (no pun intended) that we can improve this diagram and make it easier to understand. I would suggest implementing a simple scenario first and seeing how it work before moving on to the more advanced scenario (by simple I mean every time a user need to log in as if it was their first time).
One of the steps to authorize our application to access our DocuSign account requires a human to navigate to the oauth service (https://account-d.docusign.com/oauth/auth?response_type=code&scope=signature%20impersonation&client_id=...) then login to the account, and grant it access.
I've seen some references throughout the developer portal about this being something that will need done multiple times, and I've also seen it written on the same site that it only needs to be done once (the site is actually fraught with contradicting information).
Does anyone know if this step will need to be done more than once? It makes sense to me that it should NOT.
Much appreciated!
Chris
You are referring to https://docs.docusign.com/esign/guide/authentication/oa2_auth_code.html and it is a correct place for documentation for DocuSign. Now with above flow, you get two types of tokens i.e AccessToken and Refresh Token. If Access Token expires then you can use refresh token to get new set of access and refresh token and it does not need any consent from the user or a human action, it can be done using DocuSign OAUTH API from backend. But if the response to the refresh operation is an error, or if the new access token’s expires_in value is less than your threshold, you will need to repeat the initial authentication flow. So you need to do proper exception/error handling before taking user back to the consent/OAuth login page.
I have created an account with Auth0 and I am trying to get a simple login for Angular 2 to our backend API.
1. What I am trying to do is to be able to access the roles in the API to see whether the user has the correct permissions.
I have enabled the Auth0 Authorization extension I have gone in and created one group and one role, I have assigned these to a test user which I have created, I have then gone to the configuration and published the rules for token contents and persistence.
How can I view the permissions/groups from the JWT in an nodejs app? I am using express-jwt and this:
const authenticate = jwt({
secret: config.get('AUTH0_CLIENT_SECRET'),
audience: config.get('AUTH0_CLIENT_ID'),
credentialsRequired: false,
});
Which is giving me details such as iss, sub, aud. But no details on the user metadata, how am I able to retrieve this? Also as I have clearly not used Auth0 before, is it best practice to store the user details on our own databases also so I can use my own ID to store against the user actions, or is it possible to use an ID if Auth0 give one to store against user actions in our database.
EDIT 1
Ok I can see there is an options parameter for the Lock which you can pass scopes in, is it bad practice to request these when logging in? There will only really be a handful of groups/roles for now. Or is better that the API can lookup the user using the token provided to get the app_metadata to view the permissions etc, if so how can I look this up?
2. How am I able to manage the users and view them so I can display them in our own admin panel and manage the permissions they have.
For the case where the groups and roles information are available within the token itself (as groups and roles claims) and given that you're using express-jwt then you can access this information on the server-side by accessing:
req.user.groups
req.user.roles
In essence, express-jwt will make the claims contained within the token available in the req.user object.
In relation to the ID you use to identify the user you can use the value contained within the sub claim of the user token. This value is guaranteed to be unique and stable so a recurring user that uses authenticates in exactly the same way will always have the same value within the sub claim.
You already discovered that one way to include the groups and roles information is to request it through the scope parameter. It's not a bad practice to request this information to be included in the token, however, you need to take in consideration that tokens delivered through the implicit grant which is used by SPA are included as a part of the callback URL and as such their maximum size is constrained by the limits imposed on URL's.
In regards to your second question, you could implement your own management backend by integrating both the Auth0 Authorization extension API and also the Auth0 Management API; see the following links for more info:
https://auth0.com/docs/extensions/authorization-extension#enabling-api-access
https://auth0.com/docs/api/management/v2
We are using Azure B2C to authenticate our users which is working fine. After signup we add some custom claims to our users which were defined in the B2C portal as "User attributes" using the graph api. When I log into the portal I can see these values have been set by our calls, as have some standard claims values(i.e. we also set Display Name by concatenating the givenName and lastName values).
The issue we are having is that after these values are set, they do not appear in the token retrieved by sending the access token to the authenticate endpoints until the user is logged out and back in again (which is obviously a pretty awful user experience after signup). It looks like the original id_token is cached when the user is created and that is what is being returned instead.
This doesnt make sense, as it seems perfectly sensible to let a user update their profile (claims values) while logged into an application and for those changes to take affect immediately without needing to re-authenticate?
Could someone explain how/if it is possible to force the cached id_token on the server to expire so that when we request a id_token using an access token, the id_token contains the most up-to-date claims values?
The issue we are having is that after these values are set, they do not appear in the token retrieved by sending the access token to the authenticate endpoints until the user is logged out and back in again (which is obviously a pretty awful user experience after signup).
Would you mind show the request detail about how you acquire the id_token?
Based on my test, I can acquire the id_token with updated claim successful like steps below:
1 . sign-in a web app
2 . update the DisplayName using Azure AD Graph like below:
POST: https://graph.windows.net/xxxx.onmicrosoft.com/users/{userId}?api-version=1.6
{
"displayName":"newValue"
}
3. re-request the id_token from OAuth2.0 Authorization endpoint using HTTP request without sign-out/sign-in( You also can capture the exact request using Fiddler when you sign-in the app)
GET:https://login.microsoftonline.com/xxxx.onmicrosoft.com/oauth2/authorize?client_id={clientId}&redirect_uri={redirectURL}&response_type=id_token&scope=email+openid&response_mode=query&nonce=HWUavSky1PksCJC5Q0xHsw%3d%3d&nux=1&nca=1&domain_hint={XXXX.onmicrosoft.com}
4 . the update claim value show in the new id_token as expected
To narrow down this issue, you may see whether there is cache for the id_token in your app.
OK so after nearly a month of waiting for a response, the official line is:
"Product Group identify that this is on the roadmap even that we still don't have a final date it should happen in a few months."
So basically they haven't acknowledged it's a bug and they can't tell when this scenario will be supported. Pretty poor level of support to be honest.