I am using spring boot for backend and Android device for frontend of my system.
Right now I am facing the challenge to use Spring-OAuth2 to secure my resource server.
I have some questions, which I want to discuss with you:
My knowledge + this tutorial are saying that I should use the OAuth2.0 "password" grant type for my mobile app to obtain an access token. The official spring tutorial for security gives an example how to obtain the access token using password grant type:
$ curl client:secret#localhost:8080/oauth/token -d grant_type=password -d username=user -d password=pwd
And here comes my first question: Is there any possibility to obtain access token using the password grant type without sending the "client secret" ?
Since the client secret could be "reverse engineered" by decompiling the client app. The obtaining access token without secret should be somehow possible, because Facebook SDK for Android also does not need the client_secret in the mobile app.
I think here I have a little trouble understanding why the clientID + clientSecret needs to be included in the request above, because, since there are already username + password included, it should be possible to generate the access token, so does this brings a next level of security ? and does it implies the following (example): I am logged in as Filip in my Android client and I am sending the access token A with each request to the server. Then I log in as Filip into web client and I try to access the resource server from web client using the access token A, which is not possible because access token A was issued only for Android client ?
The next question is how can I refresh the obtained access token ?
I was trying to do so using the command below, but I got "Full authentication is required to access this resource." After I got the new refreshed token, can I use the refresh token to refresh my new access token again ?
curl -v --data "grant_type=refresh_token&client_id=acme&client_secret=acmesecret&refresh_token=REFRESH_TOKEN" http://localhost:9999/uaa/oauth/token
Thank you
The OAuth 2.0 spec allows for so-called public clients i.e. clients that don't authenticate themselves. So it is possible to use the Resource Owner Password Credentials grant with a public client, i.e. one that does not need to send a client secret. It does mean that the Authorization Server cannot assume anything about the client since a client_id is not a secret and there's no way to prevent a malicious client using this grant type or clients from impersonating each other. So using it in this way comes at the cost of reduced security although one may argue that in your case there's no way to use confidential clients anyhow, so there's no difference.
In general the Resource Owner Password Credentials grant is an anti-pattern for OAuth and only meant for migration purposes because it defeats most of the goals of OAuth in itself.
Access tokens are issued on a per-client basis.
You refresh token request seems OK but the Authorization Server may require basic authentication instead of providing the client_id/client_secret as post parameters, considering that you did the same for the original access token request.
Related
I have three applications: REST API with Resource Server, Authorization Server and javascript client on VueJs that should use REST Api. Problem in using access token that I get after authorization. First I decided to use local storage or cookie for storing access token, but as I read It's not secure. It's recommended to use cookie with httpOnly, but I can't to access from js. Addition token in url params as well not right way. So what I should to do for using my Rest Api? I'm using Authorization Code grant flow.
When you have a Javascript client, the client itself should act as an OAuth2 client.
Meaning, the server is not what gets the token. The client, the javascript application in the browser, will fetch the token from the authorization server.
You achieve this by using a grant type called implicit.
In this grant type, there is no client_secret, but you must have a valid client_id. You will also not receive a refresh token. But you can receive access tokens and id_token (if you have an OIDC server).
Your question hints at you doing a server side grant (authorization_code,password,etc) and then sending that token to the javascript client. This would be incorrect.
For a great description of OAuth2, we have published this video: https://www.youtube.com/watch?v=u4BHKcZ2rxk
Your JavaScript application would do this:
Do I have a valid token? No
Start implicit grant
Receive token from authorization server
Store token in memory var token = ....
Use the token to invoke API endpoints on the server
Repeat step 5 until token is no longer valid
Go back to step 1
Next step for you is to watch the video and learn more about implicit grant type
As you already guessed, going down the road of getting a token on the server and then sending it to a non secure client exposes your applications in ways you probably do not want.
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'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
Very new to okta flow, please bear with my ignorance.
I am doing a poc to access sharepoint from my external site and sharepoint is authenticated through OKTA. I want to start getting list view data from share point and expose it on my site.
1) What is the difference of authenticating using username / password flow (vs) using token to authenticate into OKTA?
Step 1: Auth in through username / password get the session token
Step 2 : After this I tried to create a session as per docs:
http://developer.okta.com/docs/api/resources/sessions.html#create-session-with-session-token
You're probably missing a valid Okta API token (cf. Getting a Token ) when calling the /api/v1/sessions endpoint. In any event, you should use the /api/v1/authn endpoint for authentication purposes and that one usually doesn't need an api token (unless you want to authenticate it from a trusted application).
The /api/v1/sessions API with the username/password payload is deprecated so you should shy away from using it in favor of the /api/v1/authn API.
I hope this helps!
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.