UseOpenIdConnectAuthentication behavior

[jlegan]

For starters I just wanted to thank both Dominick and Brock for all of their help recently, it has been invaluable. Between Idv3 and Membership Reboot I have been able to stand-up an IdP with some fairly interesting extensibility options in a short period of time.

Now that I am working through some integration with various clients I saw some odd behavior today in an MVC app while performing some integration tests with Postman.

I setup a hybrid flow client with an identity token with a 5 min exp, access token with a 5 min exp and a refresh token with a 30 min (non-sliding) exp.

With postman everything worked as expected. I made calls over and over against an api end point and after 5 mins it threw a 401 at which point I was able to refresh the access token - everything as expected.

I went to do the same thing in MVC which uses UseOpenIdConnectAuthentication and cookies for the ticket. Like before I was able to get to a controller restricted by the authorize attribute and make successive calls against the API until it timed out at which point it threw a 401 - again, everything worked as expected.

For about 10 minutes I got caught up with something else and when I came back I clicked on the controller action again to call the API (I wanted to see the header that was returned to see how best to identity an expired token 401 response) when lo and behold I was some how reauthed, with a new access token and refresh token (trace proves the two tokens changed). Thinking it was a complete fluke I reproduced it a second time and then a third

What would cause either a silent reauthentication OR for my refresh token to be used without my intervention? I am concerned because I believe I might have a security gap that needs closing but I am not sure where it could be happening. None of the MSDN documentation on UseOpenIdConnectAuthentication (MVC app) or UseOAuthBearerAuthentication abstracted by UseIdentityServerBearerTokenAuthentication (Web API)

[brockallen]

Is your OIDC middleware configured to "UseIdTokernLifetime" or whatever the property is? That should be false and you should set your own cookie expiration.

[jlegan]

My config for both are below. I do have UseLifetime turned off however I do have a sliding 15 minute exp on the cookie but would that explain how/why the following occurs?:

1. Login after hitting an [Authorize] attributed controller in the MVC app.
2. Use the access token stored in the claims to call a web api.
3. Continue to make calls until the token expires.
4. Keep making calls to the web api, each throwing a 401 since it is using the expired access token.
5. Wait ~10 minutes, click on the same controller action that was throwing the 401 above and the tokens (access and refresh) get refreshed and the web api calls succeed.

The refresh mechanism is eluding me.

Web API confg:

app.UseIdentityServerBearerTokenAuthentication(new IdentityServerBearerTokenAuthenticationOptions
            {
                Authority = CloudConfigurationManager.GetSetting("TokenAuthority"),
                RequiredScopes = new[] {Scopes.Lockdown.Management},
                RoleClaimType = Claims.Role,
                ValidationMode = ValidationMode.ValidationEndpoint,
                EnableValidationResultCache = true, 
                ValidationResultCacheDuration = TimeSpan.FromMinutes(Convert.ToInt32(CloudConfigurationManager.GetSetting("TokenCacheDuration"))),
                ValidationResultCache =
                    new RedisValidationResultCache(Convert.ToInt32(CloudConfigurationManager.GetSetting("TokenCacheDuration")),
                        RedisConnectionMultiplexer.Connection)
            });

MVC Config:

            app.UseCookieAuthentication(new CookieAuthenticationOptions
            {
                AuthenticationType = "Cookies",
                CookieName = "testCookie",
                CookieDomain = "127.0.0.1",
                SlidingExpiration = true,
                ExpireTimeSpan = System.TimeSpan.FromMinutes(15)
            });

            app.UseOpenIdConnectAuthentication(new OpenIdConnectAuthenticationOptions
            {
                Authority = CloudConfigurationManager.GetSetting("Idv3Authority"),
                ClientId = "epicenter",
                Scope = string.Format("openid profile offline_access {0} {1} {2}", "https://www.company.com/scopes/roles", "https://www.company.com/scopes/test.administrator", "https://www.company.com/scopes/idv3.administrator"),
                RedirectUri = CloudConfigurationManager.GetSetting("Idv3RedirectUri"),
                PostLogoutRedirectUri = CloudConfigurationManager.GetSetting("Idv3RedirectUri"),
                ResponseType = "code id_token token",

                SignInAsAuthenticationType = "Cookies",
                UseTokenLifetime = false,

                Notifications = new OpenIdConnectAuthenticationNotifications
                {

                    AuthorizationCodeReceived = async n =>
                    {
                        // filter "protocol" claims
                        var claims = new List<Claim>(from c in n.AuthenticationTicket.Identity.Claims
                                                     where c.Type != "iss" &&
                                                           c.Type != "aud" &&
                                                           c.Type != "nbf" &&
                                                           c.Type != "exp" &&
                                                           c.Type != "iat" &&
                                                           c.Type != "nonce" &&
                                                           c.Type != "c_hash" &&
                                                           c.Type != "at_hash"
                                                     select c);


                        // get access and refresh token
                        var tokenClient = new OAuth2Client(
                            new Uri(CloudConfigurationManager.GetSetting("Idv3TokenEndpoint")),
                            "testclient",
                            "secret");

                        var response = await tokenClient.RequestAuthorizationCodeAsync(n.Code, n.RedirectUri);

                        claims.Add(new Claim("access_token", response.AccessToken));
                        claims.Add(new Claim("expires_at", DateTime.Now.AddSeconds(response.ExpiresIn).ToLocalTime().ToString()));
                        claims.Add(new Claim("refresh_token", response.RefreshToken));
                        claims.Add(new Claim("id_token", n.ProtocolMessage.IdToken));

                        n.AuthenticationTicket = new AuthenticationTicket(new ClaimsIdentity(claims.Distinct(new ClaimComparer()), n.AuthenticationTicket.Identity.AuthenticationType), n.AuthenticationTicket.Properties);
                    },
                    RedirectToIdentityProvider = async n =>
                    {
                        if (n.ProtocolMessage.RequestType == OpenIdConnectRequestType.LogoutRequest)
                        {
                            var idTokenHint = n.OwinContext.Authentication.User.FindFirst("id_token").Value;
                            n.ProtocolMessage.IdTokenHint = idTokenHint;
                        }
                        else if (n.ProtocolMessage.RequestType == OpenIdConnectRequestType.AuthenticationRequest)
                        {
                            n.ProtocolMessage.AcrValues = string.Format("tenant:{0}", "testclient.testtenant");
                        }
                    }
                }

            });

[brockallen]

Well, monitor the HTTP activity -- it should reveal what's happening in your browser.

[jlegan]

Brock,

I will take some wireshark traces later today but I wanted to report back what I found in case you had some insight. Here was the flow:

• 9:58AM - MVC client (Hybrid) hits authorize controller, prompted to authenticate. Code exchanges hands, user authenticated, access and id token stored in claims.
• 10:00AM - Access toke expires after 60 seconds, 401's are thrown by the web API controller using that access token.
• 10:01 - 10:49AM - No user interaction between browser during this period of time. Cookie would have expired (15 minute sliding).
• 10:50AM - Refresh page whose controller action calls the web api (and is protected by the same auth attribute above), a new request is made to /core/connect/authorize by the MVC client, codes are sent and exchanged for a new access and refresh token.

[jlegan]

I believe I found the root of the issue however it is unclear on how it is happening (nor is it Idv3 and thus not your concern). With the settings I listed above, the cookies being generated by the MVC app do not have 15 min expirations but rather 1 year in Chrome and "Until end of session" in Firefox. No amount of changes I make in the UseCookieAuthentication has any impact on the cookies lifetime.

[brockallen]

The cookies will always be "until end of session" (unless you mark them as persistent) because the logon session expiration is a value in the contents of the cookie itself.

[jlegan]

Ah, I will claim ignorance on that one, I did not realize it. Then that means the expired session is somehow still authenticating, getting a new code and exchanging it for a new token without user intervention.

[brockallen]

Right -- sounds like the session expires at the client, you get redirected to IdSvr, and since you're still logged in there you get a new token, and returned back tot he client app.

[jlegan]

I realize this is going to sound like a dumb question, but by what mechanism is the user still "logged in" at the IdP? For the client in question, the exp times are:

IdentityTokenLifetime 300s
AccessTokenLifetime 60s (for test)
AuthorizationCodeLifetime 300s
AbsoluteRefreshTokenLifetime 1800s

After that 40 minute window that elapsed in the time line above, what is keeping the user logged in? I didn't realize that at any point the user was ever "logged in" to Idv3 outside of it being the issuing authority of the tokens. My Idv3 implementation is hosted in a web api project exposing other controllers necessary for it to fulfill its role as the IdP in my scenario.

[brockallen]

The cookie issued by IdSvr (which is 10 hours by default).

[jlegan]

Holy hidden grail batman: http://identityserver.github.io/Documentation/docs/configuration/authenticationOptions.html

Brock I swear I have been over the documentation time and time again and I completely missed the Cookie Options there.

If you would not mind entertaining me for a couple of more seconds I would love your recommendation.

Requirement: User access site (sensitive information) and the site makes heavy use of web api's protected by access tokens. Most sessions last less than 15 minutes however the need to support longer sessions exists.

Current Plan: MVC client cookie exp at 15 minutes sliding. Access token in the cookie exp at 15 mins, Refresh token 30 mins. Most users will never need the token refreshed however if they do it will be silent. MVC cookie will continue to extend its lifetime as they use the site after the half way mark.

Now with the information you provided, what would you recommend? The Idv3 authentication cookies are good for 10 hours, way too long for the majority of the work this IdP will be performing however the setting is global in scope, not client specific. Also, the IdP will be serving 7-8 separate solutions (loosely coupled but independent) and the idsrv cookie would appear to be global in scope.

The reason I embraced membershipreboot as my identity store is because of the need for multi-tenancy. I need for a user to be able to log into one site as "ballen" and be able to log into a different site as "ballen2" (different tenant, different sites, different clients) but using the same Idv3 server. Is that possible with the current implementation? The way this is setup make me believe that SSO is almost a requirement whereas I am trying to achieve just the opposite. The use of SSO is actually not allowed.

EDIT I can confirm that this is indeed what was happening. By adding this to my Idv3 implementation the user is forced to log back in after the MVC cookie expires:
AuthenticationOptions = new AuthenticationOptions {CookieOptions = {ExpireTimeSpan = TimeSpan.FromSeconds(1), SlidingExpiration = false}}

Would this be a safe option in an environment where a single user (human being), logging into 3 separate sites, with 3 separate user names (different tenants) against the same Idv3 instance with a 1 second cookie lifetime on the Idv3 cookie? I completely understand the need for this cookie in an SSO environment but in my case I need the clients to control the lifetime, not the IdP and eliminate the SSO capability.

[jlegan]

Brock,

Please see my observation/question above when you have a moment. If the above does not seem like a good fit, is it unreasonable to simply host 5 instances of Idv3 in the middleware, each with their own cookie configuration (prefix) but sharing the same database. There are no data separation concerns with the app, but this would give me some flexibility that I do not currently have. Of course I believe I am still OK with the solution proposed above, essentially negating the use of Idv3 cookies altogether through a very short lifetime but want to ensure that this does not have unforeseen implications.

Thanks,

Jim

[brockallen]

So you're getting 2 tokens from IdSvr: an id token and an access token (via a code/refresh token). The lifetime of the id token doesn't matter because you have have your app issue its cookie for however long you want. It just needs the id token to get started. The access token then can be re-obtained over and over purely from the refresh token.

So having said this, neither one of those depend upon the authentication cookie at IdSvr -- meaning, you could make that cookie lifetime very short so that your other apps would not get the same identity.

Is that what you're looking for? In other words you don't need/want SSO, right?

[jlegan]

Brock,

Thanks for the input. Everything token wise is working as expected. I have extended the functionality of Idv3 to include specific functionality I needed (i.e. IP whitelisting when issuing tokens) and due to the nature of the platform, SSO is not a good fit.

The design requires a many-to-many tenancy approach. For example, a customer (business) will have a tenant in each component for which they have been granted access. The tenants follow the format of {component}.{company}. While a couple of the tenants could be merged with the use of more sophisticated permission handling, this format gives me a clean separation of user credentials and solid compartmentalization. This is why the design of Membership Reboot was such a good fit.

It is of course entirely possible that an employee (John Smith) and CompanyXYZ could register for two components his company has been granted access to as:

Tenant: component1.companyxyz
User: jsmith
and
Tenant: component2.companyxyz
User: jsmith

He may even use the same password and will certainly use the same email address. This allows me much more granular control of all account events as I know which "component" the account belongs to and can alter the behavior as a result. Some components will require 2FA for example.

The MVC front end (or whatever front end happens to be in front of the API) needs to control the cookie lifetime, use the access token and refresh it as necessary. The part I was missing was the cookie that Idv3 was handing out. Since Friday I have been running in an Azure dev environment using a 1 second cookie lifetime on the Idv3 cookie and so far so good.

Thanks again

Jim