locked
Client credential Grant flow, Access token expiry configuration and key expiry max limits ? RRS feed

  • Question

  • Hi ! We are using the OAuth 2.0 Client Credentials grant flow using the AAD oauth2/token endpoint for a web client/so called "confidential client" scenario.

    In the Azure portal when registering our web client app I added a key (symmetric shared secret key) which has a 2 year expiry.

    Using this flow, by forming a HTTP post and retrieving a JWT access token, the JWT/auth token acquired appears to have a 1 hour expiry.

    I guess I was naively assuming that the access token which I would retrieve using this flow would have an expiry corresponding to the key expiry (2 years this case).

    From what I am seeing, it looks like the HTTP POST call which we use to retrieve the access token (via oauth2/token endpoint) arrives back to us with a 1 hour expiry access token. Based on this I am assuming our implementation would have to have some timer thread set at 55 minutes (in advance of the default 1 hour expiry) to do a manual refresh to retrieve a fresh authentication token to keep our service authenticated/authorized to our Web API running as an App service in the Azure cloud.

    I've also seen an MS Azure documentation article entitled "Configurable token lifetimes in Azure Active Directory (Public Preview)".

    I am not sure how we can configure the lifetime of the authentication token issued in the client credential flow.

    My questions specifically here are :

    1. Is this how the client credentials grant flow works within AAD ? i.e we use a shared secret key which has a max of 2 yrs ,  the service which retrieves the authentication token needs to schedule it's own refresh of the bearer token by re-issuing a new POST request on or before expiry. (1 hour default).
    2. If the above is true, can we configure the token to have a longer expiry ? and if so, what is the maximum expiry?
    3. In terms of the shared secret key having a 2 year maximum configurable expiration when configured from the Azure AD portal does AAD offer anything to simplify the key distribution when a shared secret key expires ?

    I understand clearly the idea that the client credential grant flow doesn't provide an OAuth 2 refresh token.

    I am just trying to understand what the OAuth "dance" is for this flow in terms of maintaining authentication on a headless system, service-to-service authentication and how can we best configure this to have long lived tokens with the minimal overhead of authentication requests under the covers.

    --Ian



    • Edited by ipxlittle Friday, February 3, 2017 11:31 AM formatting
    Friday, February 3, 2017 11:25 AM

Answers

  • Hey Ian,

    1. As you said above, that 2 year expiry is in fact your secret lifetime.  When Azure AD issues Access Tokens they do in fact have a lifetime of 1 hour.  You can check the expiration in the claims of the token, or set a timer yourself on your service.  I recommend following the former pattern.  

    For more on the actual protocol, checkout our Client Creds protocol doc that walks you through the flow and gives some examples: https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-v2-protocols-oauth-client-creds.  

    2. Token lifetimes can be configured for some oAuth 2.0 flows with Azure AD as long as it's a public client, but unfortunately client credentials does not allow for custom token lifetimes as it is considered a confidential client.  

    3. There is no clean way to refresh the shared secret key upon expiration; however, you can create a secret with an infinite lifetime in the Azure Portal to bypass the refresh every 1 or 2 years.  

    Here is a sample we've produced that's a

    .NET daemon app doing client credentials: https://github.com/Azure-Samples/active-directory-dotnet-daemon

    .NET daemon app doing client credentials w/ cert: https://github.com/Azure-Samples/active-directory-dotnet-daemon-certificate-credential.  

    Monday, February 13, 2017 6:38 PM

All replies

  • Hey Ian,

    1. As you said above, that 2 year expiry is in fact your secret lifetime.  When Azure AD issues Access Tokens they do in fact have a lifetime of 1 hour.  You can check the expiration in the claims of the token, or set a timer yourself on your service.  I recommend following the former pattern.  

    For more on the actual protocol, checkout our Client Creds protocol doc that walks you through the flow and gives some examples: https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-v2-protocols-oauth-client-creds.  

    2. Token lifetimes can be configured for some oAuth 2.0 flows with Azure AD as long as it's a public client, but unfortunately client credentials does not allow for custom token lifetimes as it is considered a confidential client.  

    3. There is no clean way to refresh the shared secret key upon expiration; however, you can create a secret with an infinite lifetime in the Azure Portal to bypass the refresh every 1 or 2 years.  

    Here is a sample we've produced that's a

    .NET daemon app doing client credentials: https://github.com/Azure-Samples/active-directory-dotnet-daemon

    .NET daemon app doing client credentials w/ cert: https://github.com/Azure-Samples/active-directory-dotnet-daemon-certificate-credential.  

    Monday, February 13, 2017 6:38 PM
  • Basically dont confuse with secret key expiry along with token expiry. Secret key is like a password which we can either set expiry or we can set infinite expiry from azure portal. But Token Life time is purely based on Signing Key  rollover of active directory. As per microsoft document , AAD signing key rollover will happen every 24 hours as of now. So if you had created token using one private-public key, the same private-public key will not be available after 24 hours. This is the reason we can set AAD Access token max 24 hours unless microsoft changes in future.

    https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-token-and-claims

    At any given point in time, Azure AD may sign an id_token using any one of a certain set of public-private key pairs. Azure AD rotates the possible set of keys on a periodic basis, so your app should be written to handle those key changes automatically. A reasonable frequency to check for updates to the public keys used by Azure AD is every 24 hours.

    Tuesday, July 3, 2018 8:56 AM