Spring Security OAuth2 Client uses HttpSession to store the access token if we use oauth2Login() to obtain the access token from Okta (Authorization server). That will force us to have only a single instance of OAuth2 client and won't be able to horizontally scale in an environment like Kubernetes.
To solve this issue I was able to find different approaches on the internet.
Use implicit flow where the access token is obtained and maintained in the browser client which is less secure to the above approach.
Once you obtained the access token in the backend, produce a new custom JWT token with all the claims copied and store it in the user's browser. So every subsequent request can be authenticated using that JWT token thereafter.
Use the Spring-Session library to share the HttpSession between multiple OAuth2 client instances and stick to plain old HTTP sessions to store access token.
What would be a better approach?
Related
I'm developing rest api in spring for my company. I need to secure it using google OAtuh2. Firstly I used jwt token validation. Frontend app obtains token_id andd pass it to backend resource server. I've read that I sholud use access tokens instead of id_tokens (is that right?). For using opaque tokens introspection I need to provide introspection uri. I can't find it. Does google auth server support token introspection?
Yes you should use access-tokens only to secure requests to resource-server(s). ID tokens are for clients to get user-info.
Using access-token introspection has serious performance impact compared to JWT decoding: resource-server must issue a query to authorization-server for each and every request it processes (when JWT validation can be done locally with authorization-server public key retrieved only once). I recomand you don't do that.
If you cannot configure authorization-server to add the claims you need to JWT access-tokens, you should consider using an authorization-server capable of identity federation in front of it. It is very common to do so when several etherogenous identity sources are used (Google + Facebook + Github + LinkedIn + corporate LDAP for instance), but it would work with a single one too. Keycloak for instance does that and allows you to put whatever you need in access-tokens.
I'm having a hard time figuring a good way to implement Oauth 2.0 and OpenID Connect authentication alongside an existing internal email+password authentication for a B2B Web app's API using Spring security.
We have a backend REST API that is a Spring Boot servlet application which currently authenticates users with OAuth 1.0 and the password grant. The front-end is an Angular single-page app through which users must log in with their username and password. The API's /oauth/token endpoint then delivers an opaque access token to be used for fetching secured resources that are then displayed within the app.
We'd like to add the possibility to log in using external authentication with OpenID connect, which is a perfect opportunity for switching to OAuth 2.0 and JWT tokens. Our API would then accept JWT tokens it delivered as well as external JWT tokens emitted by accepted issuers.
Reading and validating JWT tokens won't be a problem using Spring security's OAuth Resource Server. However things get complicated with how to make the classic username+password login flow work with JWT tokens.
We thought about delivering JWT access tokens the same way we used to with our old OAuth 1.0 tokens. The thing is, newer OAuth specifications advise against using the password grant, plus it simply isn't supported in the Spring authorization server project we're planning to use. The authorization-code flow w/ PKCE seems like too much for this case as we do not want the back-end API to render a login form but use credentials entered in the existing login form that is part of the single-page app.
I've read a lot about not using OAuth for 1st party login since its primary use is for external authentication, but again, that doesn't apply since we also want 3rd party authentication.
What would be a secure way to implement a Spring boot authorization server that can deliver JWT access tokens to a 1st party client in exchange for a user's credentials, all this using the existing log in page, and given the password grant type no longer being supported?
I thought about implementing a preliminary step that would be a POST request with Basic authentication to a /login endpoint that just returns a 200 HTTP status, then proceeding to the /oauth2/authorize request that would deliver the authorization code immediately without redirecting since my session is authenticated.
I'll be happy to provide more details if needed. Here are the resources I'm using for this project.
What about setting up an authorization-server capable of identity federation?
In such configuration, the authorization-server is responsible for providing with identities, proxying one or more sources (your existing user database for instance, plus maybe Google, Facebook, Github, etc.)
Keycloak does it for instance.
From the client point of view (your Angular app), the authorization-server is used to get:
access-token: put in Authorization header of requests to secured resource-server(s) (can be a JWT or an opaque string, doesn't matter, clients should not try to extract data from access-tokens)
refresh-token: send to authorization-server to renew access-token before it expires
id-token: get user-profile data (email, username, profile picture, etc.)
You should have a look at https://github.com/damienbod/angular-auth-oidc-client for connecting an Angular app to an OIDC authorization-server.
From resource-server point of view, access-tokens are the source ofr setting-up security-context, either by decoding and validating a JWT locally or with token introspection on authorization-server.
Have a look at those tutorials for such resource-servers configuration.
Am I correct in the following thought process?
For a native app I'm building I want to implement a backend in Spring Boot.
This backend will be secured using Spring Security. Since I will manage and develop everything myself (the backend, the native app(s) and the web app for backend management) securing everything with JWT would be sufficient and implementing a full oauth server would be a bit overkill.
I have implemented the JWT token generation in my backend at this moment. On user sign in, the backend returns a json object containing some user details as well as an access token and a refresh token. The access token will be short lived, the refresh token will be long-lived (speaking about months of life time, maybe even indefinite unless revoked).
Is it correct that the refresh token could theoretically also be used as the access token? Or should I set some value/data in the refresh token that identifies it as a refresh token only (so can't be used to access resources, only to generate new access token)?
As I know, JWT auth is definitely stateless, as a web server does not save any status of an user. However, Oauth2 is different. It stores each key of each user in an auth server, which means "stateful". No?
As I know, JWT auth is definitely stateless
No, JWT is not definitely stateless. It is just a format for signed/encrypted data and you still have to manage key materials to compute or use such token.
OAuth2 is different
OAuth2 is a framework protocol. There is no notion of server "state" in the specification. But to ensure a high security level, the servers that implement that protocol should have to manage clients, initial access tokens, access tokens or refresh tokens, authorization codes...
I'm trying to implement Spring OAuth. I'm new to it and I'm trying to understand how it works.
My Questions:
OAuth generates token after authentication and this token must be used for every request the user makes. We need to append this access_token to each REST API call for accessing the resources. Did I sound correct?
Do we need to store this token on client side (using cookies)? or is there anyway so that we do not need to store this token at client side and can be handled on the server side?
If we have to store the token on client side what's the best way to do it? I have gone through this link
If endpoint on your server is protected by oauth, then yes, you have to pass token with each request - probably in "Authorization: Bearer {token}" header. In spring its solved by using different restTemplate - OAuth2RestTemplate which automatically fetch it and add to request.
You just store just JSESSIONID in a cookie. Then spring read session from store ( disc where tomcat is installed / redis if you use spring session project/ etc )
Access token should be relatively short living. There should also be revoke endpoint available so you can invalidate specific token when there are reasons to believe it was compromised.
3.a) there is another issue with storing some data on client side. Its about storing clientId, clientSecret on mobile native apps. Android apps code can be reverse engineered quite easily, so anyone can then try to use your oauth app to get token. In those situations its recomennded to use different grant type "password" - check https://aaronparecki.com/2012/07/29/2/oauth2-simplified#other-app-types