I'm trying to implement Spring OAuth2 in my Spring REST application. What I have already achieved:
Generate a token while logging in.
Store this token on the client side, use it for every request I do from UI.
What I want to achieve:
1. Encrypt the token stored on the client side & send this encrypted token instead of sending the actual token.
Are there any services available in the Spring OAuth2 project to achieve this?
Any ideas/suggestions?
Thanks
As I know oauth2 servers and clients usually run in SSH channels, if you use SSH there is no need to encrypt theme.
Secondly access_token is stored in a cookie on client side. if you want to encrypt it you must consider which your oauth2 server should be able to decrypt it too!
Thirdly your scenario is already have been implemented by JWT!
take a look at :
https://github.com/spring-guides/tut-spring-security-and-angular-js/tree/master/oauth2
Related
So I currently have this POC that I'm tinkering right now. I was thinking if it was possible that I can implement a Spring oAuth2 with JWT with a Authorization Server and a Resource Server both in different projects?
Flow goes like this User gets a token or passes through the Authorization Server and as long as he has the token and it's not expired he can make requests on the resource server.
I think that is the usual way to implement that. You have one authorization service providing tokens, either itself is backed by a database containing user information or maybe is asking another user service if the credentials are valid. The returned tokens can be used to make authorized request against the resource service(s).
Maybe take a look at the grant flow here.
I am using AuthorizationServerConfigurerAdapter to configure my OAuth2 password flow where I am successfully creating a JWT token. I am using my OAuth2 within my Spring REST backend and pairing it with my Angular 2 fronted.
I have read several articles (eg. https://stormpath.com/blog/where-to-store-your-jwts-cookies-vs-html5-web-storage) where people are putting the JWT inside a HTTP only cookie returned to the Angular front end to prevent XSS scripting and it is of interest to me. I am confused how to integrate or intercept my jwt being returned and place this inside a http only cookie and return it.
Any Suggestions?
John
I wouldn't recommend using password flow at all, especially in a browser client. OAuth2 was designed so that you can avoid that, and thus avoid giving user credentials to an untrusted agent. If you let go of password grants, you will find that a session cookie is just as secure as your JWT cookie proposal, and it works out of the box with no funny business on client or server.
Is there a simple way to integrate Firebase Authentication with Spring Security (for a REST service)?
From what I've read, I'll probably need to use a JWT token (obtained via Firebase), use that to authenticate the Spring service, and finally verify the token within the service via Firebase. But I can't find any (simple) documentation on using JWT with Spring Security.
I'd also like to be able to provide an /auth/login endpoint that uses Basic Auth rather than JWT so that I can obtain a JWT token via Firebase using email/password credentials. But this would mean enabling Basic Auth at one endpoint in the service and JWT Auth at all others. Not sure that's possible.
Short answer: no.
Long answer: you should create your own JWT, regardless of Firebase. When you receive a JWT from Firebase, verify its integrity. Then, issue your own based on the data in the token. Then you only need to adapt it to various OAuth providers. This way you can avoid round trips to firebase on each request.
For authenticating the user on each request (stateless auth), you add a filter with highest precedence. From the http request you are filtering, get the JWT and verify its integrity. If it's all good, set the authentication in the SecurityContextHolder.
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
I’m trying to get my head around how I would introduce token-based (key-based?) authentication to a web API (currently looking at Sinatra, but maybe Rails too) that would be used by a mobile client and how OAuth would fit into the picture.
So, let’s say I want to create a web service that uses Facebook for authentication and grabbing basic user data. Here, my API would be a client to Facebook’s OAuth Server, requesting an access token upon a user’s successful login to Facebook. This would then grant me access to the user’s data which I would use to create an entry in my database, storing this user-specific token with any other application information I would like linked to them.
I think I got that part right so far, but here’s where I’m a bit confused.
I think that my API would also need some form of API key to grant access to a mobile user, since I wouldn’t want to transmit and store the Facebook key on their device. Would I have to have a separate store of keys which I provide to the client to access my service? Are there any ‘best practice’ ways of doing this?
Would I have to have a separate store of keys which I provide to the client to access my service?
yes.
Are there any ‘best practice’ ways of doing this?
The simplest way would be to generate a separate authentication token on every User creation and expose that to the mobile client. Then send it with every subsequent request header.
Devise provides a simple example how to achieve that. You don't need devise for that, just provide some token generation mechanism.
#Devise.friendly_token
def self.friendly_token
SecureRandom.urlsafe_base64(15).tr('lIO0', 'sxyz')
end
This mechanism can be extended to provide more security in following ways
Being an oauth2 provider itself.
On successfull login with facebook, you would generate an :authorization_code which the client can exchange for your own Oauth2 Bearer or MAC token within a next step. Then you can send your own Oauth2 token with every request for user authentication.
See rack-oauth2
Implement HMAC token encryption.
Generate and expose a secret_key to every client after singning in. Use this secret to sign messages along with a unique client id. The server can then lookup the secret_key for the specific client_id and verify the message.
See api-auth