1:<\/span> app.UseOpenIdConnectAuthentication(<\/pre>\n<\/p>\n
2:<\/span> new<\/span> OpenIdConnectAuthenticationOptions {<\/pre>\n<\/p>\n
3:<\/span> ... <\/pre>\n<\/p>\n
4:<\/span> UseTokenLifetime = false<\/span>, <\/pre>\n<\/p>\n
5:<\/span> }<\/pre>\n<\/p>\n
6:<\/span> ); <\/pre>\n<\/div>\n<\/div>\n
As simple as that. With UseTokenLifetime<\/span> set to false<\/span>, the cookie MW will now honor whatever settings you add in the cookie MW options.<\/p>\nThe challenge with that approach is that now the app session is entirely decoupled from the session the user has with Azure AD (or whatever IdP you are working with). That\u2019s dangerous: your app session might outlive the IdP session, which might have been terminated for good reasons (admins find out the user was compromised; lost device scenarios; and so on).<\/p>\n
Set up session renewing logic<\/h3>\n
The ideal would be to ensure that our app\u2019s session lasts as long as the IdP session, or at least approximate it. Note: the duration of the IdP session is NOT the duration of the id_token obtained when the user authenticated to your app. When your user was bounced to the Azure AD pages, he\/she went through an authentication ceremony which ended up with two artifacts:the id_token your app requested AND a session cookie bound to the Azure AD domain. That cookie is what makes possible for the user to avoid entering credentials if he\/she ends up needing in short order another token from Azure AD. The validity timeframe of that cookie is the validity timeframe of the IdP session. How can we latch to that session and ensure that our own web app\u2019 session follows it?<\/p>\n
If you ever worked with ADAL JS<\/a>, you know that it uses a neat trick (explained here<\/a>) to renew the tokens it needs for the JS frontend to access its API backend. The idea is that ADAL JS injects in the web app a hidden iframe, and uses that iframe to silently request new tokens to Azure AD. Given that the hidden frame points to the Azure AD domain, as long as there is a valid cookie for Azure AD maintaining a user session, requests for new tokens will not require the user to reenter credentials \u2013 and will obtain new tokens silently.<\/p>\nThat works for the SPA application architecture, where the web app \u201csession\u201d is really carried by the tokens attached to every web API call. In the case of apps protected by OIDC and cookie MWs, the session is really the cookie issued by the web app itself. Could we tweak the trick we use in ADAL JS to keep getting fresh session cookies from the web app as long as the Azure AD session is valid? Yes we can! Here there\u2019s a way to do it:<\/p>\n
1. add to the web app a route that will always<\/em> result in a new authorization request, regardless of whether the user is already signed in or not<\/p>\n2. add a hidden iframe in the web app, which hits the new \u201cforced\u201d sign in route at regular time intervals<\/p>\n
\u2026and that\u2019s all there is to it.<\/p>\n
The point #1 is only necessary because I am assuming you are using the ASP.NET project templates or our github samples for OIDC web apps – in the regular app templates and samples the SignIn<\/span> route only triggers the Challenge<\/span> if the user isn\u2019t signed in yet. In fact, all you need to do is to go in the Account<\/span> controller, duplicate the SignIn<\/span> method, rename it ForcedSignIn<\/span> or equivalent, and get rid of the if:<\/p>\n\n\n 1:<\/span> public<\/span> void<\/span> ForcedSignIn() <\/pre>\n<\/p>\n
2:<\/span> {<\/pre>\n<\/p>\n
3:<\/span> \/\/ Send an OpenID Connect sign-in request. <\/span><\/pre>\n<\/p>\n
4:<\/span> HttpContext.GetOwinContext().Authentication.Challenge(new<\/span> AuthenticationProperties { RedirectUri = \"\/\"<\/span> }, <\/pre>\n<\/p>\n
5:<\/span> OpenIdConnectAuthenticationDefaults.AuthenticationType); <\/pre>\n<\/p>\n
6:<\/span> }<\/pre>\n<\/div>\n<\/div>\n
That done, all you need to do is to inject an iframe in the app pages that will periodically hit the new route. For example, you can add the below right in \u2013Layout.cshtml, in the body (right after all the <div>s).<\/p>\n
\n\n 1:<\/span> <iframe id=\"renewSession\"<\/span> hidden><\/iframe> <\/pre>\n<\/p>\n
2:<\/span> <script> <\/pre>\n<\/p>\n
3:<\/span> setInterval( function<\/span> () <\/pre>\n<\/p>\n
4:<\/span> { @if<\/span> (Request.IsAuthenticated) {<\/pre>\n<\/p>\n
5:<\/span> <text> <\/pre>\n<\/p>\n
6:<\/span> var<\/span> renewUrl = \"\/Account\/ForcedSignIn\"<\/span>; <\/pre>\n<\/p>\n
7:<\/span> var<\/span> element = document.getElementById(\"renewSession\"<\/span>); <\/pre>\n<\/p>\n
8:<\/span> console.log(\"sending request to: \"<\/span> + renewUrl); <\/pre>\n<\/p>\n
9:<\/span> element.src = renewUrl; <\/pre>\n<\/p>\n
10:<\/span> <\/text> <\/pre>\n<\/p>\n
11:<\/span> } else<\/span> { <\/pre>\n<\/p>\n
12:<\/span> <text> <\/pre>\n<\/p>\n
13:<\/span> console.log(\"No renewal attempt without a valid session\"<\/span>); <\/pre>\n<\/p>\n
14:<\/span> <\/text> <\/pre>\n<\/p>\n
15:<\/span> } <\/pre>\n<\/p>\n
16:<\/span> }, <\/pre>\n<\/p>\n
17:<\/span> 1000*60*45<\/pre>\n<\/p>\n
18:<\/span> );<\/pre>\n<\/p>\n
19:<\/span> <\/script><\/pre>\n<\/div>\n<\/div>\n
It\u2019s that simple! With that JS in place, the app will trigger a new sign in, completely transparently, every 45 minutes. Note that this will happen only if the current web app session is still valid. If there is a valid Azure AD session, the app will successfully drive a new authentication dance that will result in a new cookie; otherwise \u2013 no harm done.<\/p>\n
I made a little test just to be sure. I created two apps, one with the session refresh trick and one without. I deployed both to their own azure websites. I opened Chrome and signed in in both apps, from 2 different tabs, at 10:12pm. Then I selected the tab with the app without session trick, and started watching Mockingjay part II (don\u2019t judge me. Also, meh).
At 23:20 I went back to Chrome, selected the tab with the app with the session trick, and clicked on About. I got access right away \u2013 sign that the session was still valid.
I switched to the tab with the app with no session trick. I clicked about, and sure enough I got redirected to Azure AD before gaining access \u2013 sign that the session expired as usual. Fiddler:<\/p>\n
![\"clip_image002\"](\"https:\/\/www.cloudidentity.com\/blog\/wp-content\/uploads\/2016\/07\/clip_image002_thumb.jpg\" "\\"clip_image002\\"")
<\/a><\/p>\n![\"Smile\"](\"https:\/\/www.cloudidentity.com\/blog\/wp-content\/uploads\/2016\/07\/wlEmoticon-smile.png\")
<\/p>\n