Imagine the following scenario.
User visits a site A (ASP.NET), authenticates using ADFS and gets a set of claims . At some point, they need to register for an additional service so they are redirected to a provisioning site B (ASP.NET) (also using ADFS – so SSO) where they register by entering their relevant details and are redirected back to A.
However, part of the provisioning process added attributes to a repository (normally AD) and we would like those attributes to form part of their claim set.
To do this they have re-authenticate? Is the best way to do this by forcing a federated logout? Would this be done by site A or site B?
If they are internal users using WIA, they would be logged in “behind the scenes” and the whole process would be transparent.
What if they are external users using FBA? Wouldn’t they have to log-in again? Given that this is not a very satisfactory user experience, is there a way around this?
There are some references out there that talk about writing a signed token as a cookie to the client browser and then the STS later authenticating the SSO token from the cookie. How would you do this with ADFS?
Have a look at the blog post I wrote about a similar scenario:
Refreshing Claims in a WIF Claims-Aware Application
In this case, the user is logged out locally but then redirected back to ADFS where they are "signed back in" since their ADFS cookie is still valid. This little hop is mostly transparent to the user and will update the claims.
Related
I need to login to Auth0 without login prompt on my intranet under certain circumstances.
I have a very particular use-case, where I have created a very special user in auth0 called "analytics" which has access to some of our analytics in Tableau.
I created it, so I know the login password and can create refresh tokens with unlimited life.
I had to create this user in auth0 and have it managed by auth0 because that's how our company access Tableau and I can't change this policy.
In another web application, which doesn't use Auth0 at all and has its own authentication methods, I need some users to have access to the ressources that the "analytics" user can access. (there also, no way to change this web application to use Auth0, because that's another company policy and I can't change it)
To achieve this, I have no choice but to allow all logged in users of the web application to be also automatically logged in as "analytics" in auth0.
Since this is an intranet, it is perfectly ok to hardcode a refresh token or login password. Also there's nothing too confidential about the analytics in question.
I know how to use the refresh token to call an API, but I don't know how to use it to "login" the user, e.g. his browser has the right cookie so auth0 knows that his browser is indeed him.
Is there any way to achieve this ?
I don't understand very well the OAuth 2.0 protocol, hence my question.
We have an ASP.NET MVC application that uses Okta for user authentication.
When an unauthenticated user browses to our app, they are redirected to Okta to log in and are then redirected back to the application, authenticated. When they click "Logout" within the application, they are signed out of the application and signed out of Okta.
The issue is when we click "Logout" from the Okta dashboard. When a user clicks "Logout" from the Okta dashboard, they are signed out of Okta but not signed out of our application. When the user logs in with different credentials in Okta and opens the application, HttpContext.User.Identity still contains the previous user information.
Is it possible to set things up such that when a user clicks "Logout" within the Okta dashboard they are also logged out of the ASP.NET application? What's the best way to accomplish this?
This is the expected behavior, let me explain.
Let's assume a user is not logged into Okta OR your application. When a user visits your application and clicks "Log In", they are then redirected to Okta to authenticate. When they authenticate to Okta, a new session cookie is created so the user's identity is remembered on the Okta domain (for example, blah.okta.com).
Then the user is redirected BACK to your application (yourwebsite.com) where they will have an access token and a NEW session cookie (on the yourwebsite.com domain) which will keep them logged in there.
So at this point, there are two separate sessions that are active:
One on your domain (yourwebsite.com)
One on Okta's domain (blah.okta.com)
When a user logs out of Okta's dashboard, this means that their token is revoked and the session cookie is deleted (from the Okta blah.okta.com domain). BUT, there is no way for Okta to delete the session cookie from YOUR website (yourwebsite.com).
Therefore, when your user does something on your website (yourwebsite.com), the user's browser will STILL send the session cookie to your backend that contains an Okta access token.
And... Depending on how your web application is configured, it will do one of two things to verify that token:
It can either validate the token locally using a JSON web token library (which is the default behavior), in which case the token is still valid, so the user is considered "authenticated" and will continue to be able doing things even though their token has been revoked.
It can validate the token against Okta's authorization server (this is called token introspection), which is a bit slower as it requires an HTTP request to Okta. If this is done, then the user will indeed be recognized as logged out and their session will be destroyed.
So basically, to get the behavior you're talking about, you need to modify the way your web application is validating the user's tokens. You need to switch from using LOCAL VALIDATION to TOKEN INTROSPECTION.
Unfortunately, we don't yet have the option to use token introspection in our ASP.NET library. The author of the library has just added that to her backlog =)
I have developed my own OAuth2 / OIDC web-application using IdentityServer4 which works fine. This is at https://myauthservice.com
I then have a separate website which is a registered client of my IdentityServer4 service which is located at https://mywebsite.com.
Both websites are made using ASP.NET Core 2.1.
The / (homepage) of https://mywebsite.com has no authorization rules applied to it.
However if a user is already logged-in if( this.User.Identity.IsAuthenticated ) then they're redirected to their account page (/account) which does have an authorization rule, if the user is not authorized (e.g. because they're unauthenticated) they're redirected to https://myauthservice.com's login page with a returnURL set.
The homepage also has a HTML Login to your account link which when clicked causes the login process described above to happen.
The problem is when a visitor has already logged-in to https://myauthservice.com but has not already visited https://mywebsite.com then they get redirected to https://myauthservice.com's login page, which sees they're already authenticated there (by checking the myauthservice.com cookies) and redirects them back to https://mywebsite.com with the right access_token.
I want to eliminate that step, so that users on https://mywebsite.com won't see the "Login to your account" page nor suffer two browser redirects if they're already logged-in to https://myauthservice.com - but https://mywebsite.com won't have the user's access_token so what's the solution?
I understand I could have a hidden <iframe> on https://mywebsite.com's homepage / that points to https://myauthservice.com's login page (with returnURL set) which would return the access_token correctly and then a client-side script would detect it and automatically redirect the user to the /account page, but this also feels like a hack.
Another option is to modify the login process on https://myauthservice.com to include a hidden reverse <iframe> that causes the browser to send the access_token to all websites I trust (not just https://mywebsite.com) to get the right cookies beforehand, so when they eventually do visit https://mywebsite.com they'll already have the auth cookie present and be redirected to /account on the first request.
What guidance from the IdentityServer4 team or OAuth2/OIDC community exists for this scenario?
Update: I now realise I'm basically asking how to implement true single-sign-on using IdentityServer4. StackExchange solved this problem back in 2010: https://stackoverflow.blog/2010/09/11/global-network-auto-login/ - I need to see how they did it.
Assuming you want to stick to using standard OpenID Connect stuff, you can use a prompt=none authorize request which will tell you if they’re already authenticated or not. This can work on client side (iframe) or server side redirect (no ui shown so user will be unaware). If you receive an error code of login_required you know to then initiate the regular sign in flow, otherwise you’ll receive the ID and access token and you can perform a local login as normal.
In practice it works well and isn’t a hack at all as this approach is part of the OIDC session management spec.
Using an ASP.NET Core 2 application with IdentityServer 4 as an identity provider. Using two ASP.NET MVC 5 applications which use the the above mentioned application as the authority for authentication. Using the implicit flow for authentication.
The first application doesn't have any page available to anonymous users, so when unauthenticated users navigate to it, they are redirected to the IdSrv app to log in. Let's call it "Admin portal"
The second application's welcome page is available for anonymous users and unauthenticated users are not automatically redirected to the IdSrv app when visiting it.
If they try to visit some page which is not available to anonymous users however, the authentication component does its work and redirects users to IdSrv to authenticate first.
If authenticated users navigate to this welcome page, the application redirects them to some other page automatically (i.e. a dashboard page) which is not available to anonymous users. Let's call this second application "User portal".
Now to the problem.
Consider the scenario where a user logs in to the Admin portal and later goes to the User portal. Even though users had been logged in to the system by using the Admin portal, when they navigate to User portal they might do so via the welcome page which does not detect if users are logged in or not, since the welcome page allows anonymous access.
The desirable behavior would be, for an user which was already authenticated, to automatically be redirected from the welcome page to some dashboard page.
Is it possible for a page which allows anonymous access to somehow ask the IdentityServer whether the current user has been authenticated already? If not authenticated, it would just show the content, and if already authenticated, it would perform a redirect to some other page suitable for the authenticated user.
I had solved this previously (I haven't been using IdentityServer back then) by having the authentication service know which pages were allowed for anonymous users, and redirecting all unauthenticated users to the login page on each request. Then the authentication service would read the returnUrl value and if it matched one of the allowed pages, users would just be redirected back to the anonymous page, with added "anonymous=1" query parameter to prevent an infinite loop. Having "anonymous=1" query parameter would instruct the application to not redirect the unauthenticated users to the authentication service. But this seemed hacky.
Any thoughts?
As McGuireV10 mentions, you may be able to use the prompt=none approach from the client side here. You issue your authorize endpoint request in a hidden iframe and if the response comes back OK (i.e. not login_required) then you know the user is already authenticated on the IDP. It's a little fiddly to implement but it is an "official" approach and forms part of the session monitoring spec.
I am new to oauth 2.0 and reading up on it. I tried using oauth 2.0 for my app with 37signals site and ran into a problem. Now sure if its as designed. Any here is what I see.
User is already logged into 37signals site.
My app starts the oauth flow by redirecting him to 37signals site
An authorization page appears asking the user if he is okay with granting access to my
app.
User approves and is brought back to my app. (An access token
is also available)
Now, user logs out of 37signals site.
User tries to use my app. My app starts the oauth flow by redirecting him
to 37signals site.
The user logs in using login screen.
He is again shown the authorization page. Shouldn't this be skipped since
the user approved it the first time? Or is this as designed?
Anyway, this does not seem very user friendly to me i.e showing the approval page every time after logout.
I noticed similar behavior with twitter as well. I initially posted a similar question while using a nodejs oauth library. Then I thought its a general oauth 2.0 question.
everyauth always triggers authorization
Upon initial authentication, the authentication provider, in this case 37Signals, will provide an authentication token. In company with your application key, you can use the users token to authenticate them subsequently, following the initial authentication. It's customary for OAuth providers to expire authentication tokens over time, in which case you would need to have your user re-authenticate.