You publish an application named MyApp to Azure Active Directory (Azure AD). You grant access to the
web APIs through OAuth 2.0.
MyApp is generating numerous user consent prompts.
You need to reduce the amount of user consent prompts.
What should you do?
A.
Enable Multi-resource refresh tokens.
B.
Enable WS-federation access tokens.
C.
Configure the Open Web Interface for .NET.
D.
Configure SAML 2.0.
Explanation:
When using the Authorization Code Grant Flow, you can configure the client to call multiple resources.
Typically, this would require a call to the authorization endpoint for each target service. To avoid multiple
calls and multiple user consent prompts, and reduce the number of refresh tokens the client needs to
cache, Azure Active Directory (Azure AD) has implemented multi-resource refresh tokens. This feature
allows you to use a single refresh token to request access tokens for multiple resources.Azure, OAuth 2.0, Refresh Tokens for Multiple Resources
Tiz A
http://www.cloudidentity.com/blog/2013/10/14/adal-windows-azure-ad-and-multi-resource-refresh-tokens/
This is exceptionally useful. To put things in perspective: a MRRT can play for all the resources in a tenant a role similar to the one played by a TGT in Kerberos. Prompts are reduced to their bare minimum, and you can start to think about sessions it terms that are closer to the ones we are used to on-premises, while at the same time maintaining the flexibility and boundaries-crossing capabilities that OAuth2 affords.
The MRRT are still valid today (the link to easy gave is 4 years old at the time of writing and Azure has evolved significantly):
https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-token-and-claims
“Refresh tokens are security tokens, which your app can use to acquire new access tokens in an OAuth 2.0 flow. It allows your app to achieve long-term access to resources on behalf of a user without requiring interaction by the user.
Refresh tokens are multi-resource. That is to say that a refresh token received during a token request for one resource can be redeemed for access tokens to a completely different resource. “