v2.0 Endpoint - Auth Session Lifetime

Question

Hi,

We have a web application that lets users log in with their Azure AD account, using the v2.0 endpoint. If they log in a second time in the same browser session, then the v2.0 endpoint remembers the user and they are logged straight in without being prompted for their username or password.

How long does the session last on the v2.0 endpoint, and is the duration configurable in any way? https://support.microsoft.com/en-us/kb/2507767 suggests that it lasts 8 hours, though we've found it to last longer than that, e.g. if the browser is left open overnight.

Also, is there any easy way for the user to manually end their session? Logging out of Office365, or browsing to https://login.microsoftonline.com/logout.srf do not seem to end the session. https://login.windows.net/logout.srf does end the session, but the URL is not documented anywhere - is it officially supported?

Thanks,
Graham Esau

Answer 1

Hello,

We are checking on the query and would get back to you soon on this.

I apologize for the inconvenience and appreciate your time and patience in this matter.

Regards,

Vijisankar

Answer 2

Hi Graharm,

Based on your description, the issue seems relative to your application session. Because if your application session is time out, it will redirect to the authenticate page of Azure and it will prompt the users like figure below:

The cookie expired time is for 14 days by default when we using the OWIN cookie meddler ware.  We can change it CookieAuthenticationOptions. ExpireTimeSpan property.

The OpenIdConnect end_session_endpoint is not currently supported by the v2.0 endpoint. This means your app cannot send a request to the v2.0 endpoint to end a user's session and clear cookies set by the v2.0 endpoint. To sign a user out, your app can simply end its own session with the user, and leave the user's session with the v2.0 endpoint in-tact. The next time the user tries to sign in, they will see a "choose account" page, with their actively signed-in accounts listed. On that page, the user can choose to sign out of any account, ending the session with the v2.0 endpoint.

 

More detail about V2.0 protocol about OpenId-connect, you can refer here.

Regards & Jupiter

Answer 3

Hi Jupiter,

We're not experiencing that behaviour. When the user's session in our application has ended and they try to sign in using OIDC, the v2.0 endpoint remembers them and immediately signs them in without prompting them to choose an account or enter their password.

We are using the endpoint for a specific Azure tenant rather than the common endpoint, does that affect the session behaviour?

Thanks,
Graham

Answer 4

Hi Jupiter,

Thanks for your help on this, but I'm not sure what you mean about validating the tenant. If we use common as the authority, would we have to then validate the tenant in our application? If not, how can we specify which tenant we expect the user to log in with?

Thanks,
Graham

Answer 5

Hi Graham,

Sorry for the confusion. There is no need to write the custom code to validate the tenant in the application.

When Azure AD receives a request on the /common endpoint, it signs the user in and as a consequence discovers which tenant the user is from. And for a user to sign in to an application in Azure AD, the application must be represented in the user’s tenant.

Since the application is a single tenant application, when the users from other tenant try to sign-in your application, it will get the error message like ' Resource 'xxx' does not exist or one of its queried reference-property objects are not present.'

You can get more detail about common endpoint from here.

Regards & Jupiter

Answer 6

Hi Jupiter,

Thanks, I understand now. However, our application actually is multi-tenant. We just a specific tenant's v2.0 endpoint because at that point in our login flow we will have already identified which tenant the user is part of.

So as I understand it, if we were to use the common endpoint then we would have to validate the Azure AD tenant in our application.

Thanks,

Graham

Answer 7

Hi Graham,

>So as I understand it, if we were to use the common endpoint then we would have to validate the Azure AD tenant in our application.

Yes, you are correct. And here is the code that use the ValidateIssue delegate to verify the issues for your reference:

     TokenValidationParameters = new System.IdentityModel.Tokens.TokenValidationParameters()
                    {
                    
                      IssuerValidator =(issuer,token, tvp)=>{

                          var ValidIssuers = new string[] { "https://sts.windows.net/04e14a2c-0e9b-42f8-8b22-3c4a2f1d8800/" };
                        
                          if (ValidIssuers.Contains(issuer))
                              return issuer;
                          else
                              throw new Exception("Invalid issuer");
                      }
                    }

Regards & Jupiter