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
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.
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)?
I have implemented a spring boot application which does authentication and authorization using Spring OAuth2.
I am using JDBC token store to main the token issued to the client for performing Custom claim verification and some other user status verification during application run-time.
The question is, since i had used traditional JSESSIONID with CSRF token, i cannot find any advantage with the new OAuth standards because after login i would store the user details in the session and retrieve it whenever needed similarly for OAuth i store the User details in the JWT token itself and decode the token every time to get the user information, also i need to hit the database anyway for custom claim verification such as JTI verification .
Everyone says JWT is for stateless application but with JDBC token store i'm holding all the token that is issued to each client. Also there is an additional overhead to purge the expired token which will be done automatically with Session. Also i'm using refresh token as the way to implement session timeout.
Therefore can anyone explain me, when should i use JSESSIONID and when to use JWT ? My application is running on AWS architecture.
From my experience, cookie-based authentication sufficiently complicates scaling and load-balancing. If you have authenticated via the first service replica, your cookie will be not appliable to another replica, cause all sessions are stored in memory. So, if you want to scale your service in the future, session-based authentication can make things much more complex.
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?
I'm considering using authenticated encrypted JWT tokens to authenticate / authorized access to an ASP.NET Web API application.
Based on what I've read so far, it seems to me like it is an option to generate JWT tokens from a token service and pass them to Web API via the http authorization header.
I have found some good code examples on implementing the JWT creation and consumption (Pro ASP.NET Web API Security by Badrinarayanan Lakshmiraghavan).
I'm trying to understand if I need a full OAuth implementation to support this, or if I can simply pass the tokens along in the auth header.
Assuming the tokens are properly encrypted and signed, is there any inherent security flaw in keeping things simple without having to use OAuth?
Trying to keep things as simple as possible for my needs without compromising security.
It is not that you must always OAuth when you use tokens. But given the fact that your application is a JavaScript app, you would be better off implementing a 3-legged authentication. Thinktecture identity server does support implicit grant. But if the client application getting access to the user credential is not a problem for you, your JavaScript app can get the user ID and password from the user and make a token request from a token issuer ensuring the user ID and password are not stored any where in JavaScript app (including DOM). This request for token can be a simple HTTP POST as well and it does not need to be anything related to OAuth. If your end user will not enter the credentials in the client application, OAuth implicit grant is the way. BTW, you don't need to encrypt JWT. TIS issues signed JWT and that will ensure token integrity. But if you are worried about the confidentiality, you can use HTTPS to both obtain the token as well as present the token.
It looks like you don't really need auth delegation as the one provided by OAuth. Isn't HMAC authentication enough for your scenario ?. With HMAC, you will not have to deal with JWT at all. This is an implementation I made for HMAC authentication for .NET
https://github.com/pcibraro/hawknet
Pablo.