I'm trying to understand how to make sure that a logged on user's account is still "valid" (where valid means for example not locked out, not deleted)
I've set up an identity provider using IdentityServer v3. On the "relying party"-side, I have an ASP.NET WebApi hosted using Owin. On the RP-side, I'm using UseOpenIdConnectAuthentication to install the OpenIdConnectAuthenticationMiddleware in the Owin pipeline.
What's working so far:
Any unauthenticated user visiting my web app is redirected to the login page on IdentityServer
The user logs on (I'm using the implicit flow)
The user is redirected back to my web app
My web app receives the JWT containing the id token and access token
My web app calls the user info endpoint to retrieve the claims using the access token
My web app creates a new ClaimsIdentity containing the claims my app is interested of. This is then persisted in a cookie, using:
app.UseCookieAuthentication(new CookieAuthenticationOptions
{
AuthenticationType = "Cookies",
SlidingExpiration = true
});
This works fine, but I want some kind of hourly validation that the user is still "valid" from the identity servers perspective.
Is there some standard pattern how I should re-validate that a user account is valid? I don't want to force the user to log on again, I just want to confirm that a user can't stay on forever even if his user account is deleted.
You can send the user to the Authorization Server again with an OpenID Connect authentication request but with the additional parameter prompt=none as documented in the spec: http://openid.net/specs/openid-connect-core-1_0.html#AuthorizationEndpoint If that returns successfully, the user is still logged in, else an error will be returned. The user will not be prompted in either case.
Related
currently, I'm working on an application in which we want to offer a single sign-on experience, but let me put you in the context:
We have two different Cognito clients created for the same Cognito pool, both are configured to allow the users to login into two different applications:
App A: mydomain.com
App B: appb.mydomain.com
well, the thing is that when a user uses the hosted UI to log in to the first application, I noticed that the Cognito server creates a cookie called "Cognito" as can see in the image:
Cookie set by the auth server
Then, when a user tries to access the other application appb.mydomain.com, and the application, instead of showing the hosted UI, the user automatically enters the application without going to all the login process again, and this is possible because of the cookie I mentioned (when I delete that cookie, then the user is requested to login again using its credentials).
So, that's nice because the user doesn't need to go through all the login process again. But my situation is the following:
I want to create a login page in mydomain.com with my own customized form and using the Cognito SDK. I already have the backend working, also the frontend. The backend can authenticate users to get the JWT tokens (IDtoken, refresh token, etc.) as you can see in the next image:
Tokens I get when I authenticate a user
But at this point I'm not able to redirect the user to appb.mydomain.com with a valid session, I mean, I have the JWT tokens, and I tried to do the same thing that the hosted UI clients are doing, that is setting a cookie somehow containing the JWT session. But I don't know how to make the application appb.mydomain.com to be able to detect this cookie. But the most important problem is that I really don't know how to construct a valid cookie (like Cognito's) to be detected by mydomain.auth.eu-west-1.amazoncognito.com (this domain is shared for both Hosted UI clients).
I don't know if this approach is feasible, or if there is another approach to send a JWT token to the auth server with a callback to redirect the user to the appb.mydomain.com
without going to all the login process again or something like that.
Do you have any advice on how to implement this kind of SSO Experience? I'm using .Net Core in the backend.
We have a web app in which we allow users to log into the app using any Open ID provider(e.g. Okta, Google, Facebook etc.). We want to implement the correct Open ID Connect prescribed methodology/workflow to keep the user logged into the site.
The existing implementation, looks at the expiry of the Access Token then if it's close to expiry uses a Refresh Token to get a new Access Token to keep the user logged in. I feel like this is wrong. When a user logs in to the web app, the Identity Token is used to Authenticate the identity of the user using the Authorization Code workflow. The Access Token and Refresh Token are stored on the server side. Periodically, the Refresh Token is used to get new Access Tokens to keep the user logged into the site. I believe this is a security risk because -
Imagine if a user is logged onto his OP account in a browser. He opens up Sky and is directly logged into MP because he’s already logged into MP. He then in a separate tab, logs out of his OP account. He will continue to be logged into MP for days on the basis of this Refresh Token/Access Token mechanism! Isn’t this a security risk?
If feel like the correct way to go about this is to use Session Management using iframes as prescribed here on OIDC -
https://openid.net/specs/openid-connect-session-1_0.html
For more context, when a user logs into our WebApp we pull data from the OP's UserInfo endpoint to create a profile within our WebApp and set permissions/roles within our app based on data sent over from the OP's UserInfo endpoint. We continue doing this periodically. For this purpose, I feel like using the Access Token(and using the Refresh Token to get new Access Token) to access the UserInfo API is correct because it conforms to the OAuth 2.0 concept of protecting/authorizing API/Resource endpoints using Access Tokens.
I want to know if this is indeed the correct way to manage how a user should be logged in when supporting Open ID Connect.
I think the first question is whether you want to bind the lifetime of an OpenID Connect provider Single Sign On session with the session of your application. You just want to authenticate a user using their OpenID Connect service. If I logout of Google, I expect to be logged out of GMail, but not a third-party application that used Google for authentication. Would you like to implement Single Sign Out as well?
But if I wanted to be logged out when you logout of the OpenID Connect provider, I would implement the OpenID Connect Session management. There is one thing good to be aware of when using iframes and cookies - browsers have an option to "Block third-party cookies" (that's how Chrome calls it), it's turned off by default, but as far as I know, it disables the SSO functionality when turned on.
I'm not sure why you request the userinfo endpoint periodically. If you just want to check whether the access token is still valid, you could also use the token introspection endpoint.
For security concerns, I would suggest you to read the OAuth 2.0 for Browser-Based Apps RFC. It recommends using the auth code flow with PKCE instead of the implicit flow. With the implicit flow, access tokens transported in redirect URLs stay in network and browser caches and can be used right away by an attacker. The auth code with PKCE needs a code_verifier (one-time secret) in order to be exchanged for tokens. So I would first check how the providers work with a configuration you choose and if it's even supported.
I am trying to implement a OAuth2 Provider, that authenticates users with a custom login.
For understanding I looked at the Spring Boot OAuth2 Tutorial.
I don't quite get, how I can implement my own Authentication meachnism to work with the OAuth2 SSO from my Server.
I want to add custom authentication mechanisms (like "user has to answer a question for authentication" or "user has to enter id and click button for authentication") instead of the Facebook and Github examples.
I read about implementing my own AuthenticationProvider, but I am stuck how to combine all the puzzle parts.
Let's go one step at a time. OAuth is only authz provider so not talk about authentication. Now for your usecase specifically, if you want user to be authenticated then OAuth authz code based flow makes sense (You can even go for implicit flow, check rfc 6749). Now how will this work for you. I am picking up the implicit flow for simplicity, Authz flow is just extension of it where end client gets a temporary code which it exchanges with Identity Server later to get the access token. Here are the steps:
Client App hits the /authorization uri with data as per rfc 6749
After validating the submitted data, server forwards user to Login page (or other page for authentication). After authentication, cookie is set in the browser or data is stored in server to mark a user as authenticated.
After authentication server redirects user to user consent page (You can even skip this if needed depending on need, But OAuth 2 spec contains this) where user specifies which all permissions (scopes) are allowed, here user can allow either allow or deny.
if user allows then these permissions are submitted to server and then server stores the data and redirects the user to client URI with access token in # fragement of client redirect URI (callback URI submitted during actual request)
I have an auth server built using spring boot oauth2.0 and follows david_syer model.
My auth server does following -
Let user login via third party oauth provider like google or let user create his account on our server using username and password and generate token.
So, when user uses external oauth like google to login then I simply store the token and pass the same(google) token to my UI app for accessing resource api servers. I have an authentication filter that verifies token and allow api access.
When user uses username and password to get token we store user and his permissions and generate a token for him. Now UI uses our auth servers generated token to access resource api servers.
Now my question is
Is this the correct way of using token from external api and using the same to access our resource api server?
And how do I add authorities to user who are signing up using 3rd party oauth provider since I don't add user entry and authorities for them?
So, spring security which loads user and user authorities (loadUserByUsername() from UserDetailsService) will not have any thing if user came from eternal provider.
I have a suggestion for step 2:
After the user uses the google authentication, and gets redirected back to your application page, do the claims transformation on your server and generate your own token issued by the identity server that you have.
The reason is you will be able to provide specific claims and the claims names does not necessarily required to match up.
That way you keep verifying your own token all the time on the client app. So lets say the user uses Facebook instead of Google and even in that scenario as you will assign your own token, you need not to verify the token coming from different third party Identity servers.
That way, your identity server trusts Facebook, Google provided token and your application will trust only your identity server so your app doesn't need to know about what IDP is issuing the token.
And with the approach I suggested above, you will be able to even modify the claims for the user on your own and don't have to depend upon the third party identity server to provide claims.
I have a Spring (3.2) based web app that a user can log into. The site will also provide an API secured via OAuth 2.0. My question then, is how do I go about generating a token for a logged in user?
The underlying idea here is that there will be a mobile app that opens up a web frame to the login page, which will eventually redirect to a url schema with an oauth token that the app will catch and then use for the api calls. Looking at the code for TokenEndpoint, I see that it defers token creation to a list of TokenGranter types. Should I be creating my own TokenGranter extended class, or am I looking at this all wrong?
I ended up writing a controller like this:
OAuthClientRequest request = OAuthClientRequest
.authorizationLocation(csOauthAuthorizeUrl)
.setClientId(csClientId)
.setRedirectURI(
UrlLocator.getBaseUrlBuilder().addSubpath(AUTH_CODE_HANDLER_URL).asUnEscapedString())
.setResponseType("code")
.buildQueryMessage();
UrlUtils.temporarilyRedirect(httpResponse, request.getLocationUri());
return null;
Then handling the code returned. My big problem here was that I had the /oauth/authorize endpoint set to use client credentials. Once I realized that tokens were being issued for the client ID instead of the user, it started to make sense.
So you want to use the Authorization Flow of OAuth. Spring has already support that, if you have configured the spring-security-oauth correctly, you just have to redirect the user/your mobile apps to /oauth/authorize?client_id=xxx&response_type=code this will redirect user to authorization page, if user has not login yet, it will redirect the user to login page then to the authorization page.
After the user completed the authorization process, it will redirect the user to an already registered redirect_url parameter with the authorization_code 'yourapp.com/callback?code=xxxx'.
Your application should exchange this authorization_code with the real token access to /oauth/token?grant_type=authorization_code&code=xxxx&client_id=xxxx&client_secret=xxxx
After that you will receive the token access that can be used to access the resource server.