I am using Spring oath to secure my RESP API's and successfully generated the oauth token. Now I am stuck in 2 place mentioned below.
1) Logout: I didn't find any URL in specification which I can call to logout/invalidate the token. One option I got is to write own implementation of logout and delete the token from the token store from that method. But is there any other way to logout/invalidate the token like we retrieve the token.
2) Validation of Token: Is there any url where I can pass my token and can validate that the token is valid or not. One way is to write a own method from which I will validate token. If own method returns 200 then valid token else invalid token(401). But like to know that , is Spring OAUth provide any such url.
The most common usage is to integrate Spring security with a standards based cloud authorization server, in which case you can use these options:
Logout occurs when a UI calls the End Session Endpoint
Tokens can be validated by APIs either in memory or via an Introspection Endpoint
Note however that not all Authorization Servers implement these endpoints in a standard way.
Deleting tokens on logout is the most standard option, along with keeping tokens short lived so that they expire soon anyway.
Related
Lets say I have created my own application. We have react front end and RESTful API as backend and we are using Google OAuth for Authorization of our users. Front end is making calls to the APIs. Front end uses Authorization Code Flow of OAuth. After getting access token from Google OAuth server, front end uses this token to make calls to my backend.
Now Malicious user will get my API's URL, other information required for REST API from Chrome Network tab and can call directly to APIs with access token.
Questions:
How will my REST API know from where the request is coming?
Also how it will validate the access token?
Is it possible once User got all information about my REST API, it can call directly with fake access token?
I have look into the diagram for Authorization Code Flow. Below is the link.
https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-app-types
But how will web api validate the token?
Please guide me if I am lacking some information.
Google's OAuth server will issue your front-end a JSON Web Token (JWT). This token is singed by Google private key. Your API needs to:
Obtain Google's public key and
Verify the signature of the JWT.
If that is valid, the token originated from Google. If not, it didn't come from Google or was tampered with.
After this, your API needs to do a few additional checks:
Check the expiration time and see that it's not in the past. This can be found in the exp claim.
Check that the token is not only from Google but for your API. This can be done by looking at the aud (audience) claim and seeing that it's for you.
Check when the token was issued, and ensure that it's not in the future. The issuance time is in the iat claim.
Check that you should start using it already, and there wasn't some sort of embargo on the usage period. This will be indicated in the not-before claim (nbf).
Check that the type of token is an access token (as opposed to an ID token).
(You can find a longer more detailed description in this howto.)
If you do these things, you can be sure that Google issued the token and that it was intended for your API. It does not indicate to your API that the caller was your front-end. The reason is that the token is an "bearer token", meaning the token is bound only to the one that bears or presents it. To ensure that only your app provides the token, you need it to prove possession of a private key. This is not possible when using Google as your token issuer (to my knowledge).
My question is basically how do my rest api validate integrity of the token. I found the link: https://developers.google.com/identity/sign-in/android/backend-auth
While starting to integrate auth0, I came across this article
So its clear that to secure apis, all we need is the access_token and that is sent with each http request in the request Authorization header(Bearer scheme).
But then auth0(and possibly other providers) also send an Id_token that contains information about the user. My confusion is that how do I use this id_token to pass user information to my api. ( I have a spa running front end that authenticates to auth0 and gets these 2 tokens).
I can ofc call the userInfo end point in my api to get user info. But then wouldn't this defeat the purpose of the Id tokens?
The ID Token is consumed by the application and the claims included,
are typically used for UI display. It was added to the OIDC
specification as an optimization so the application can know the
identity of the user, without having to make an additional network
requests.
So my question is how do I access user profile in my api using id tokens?
"My confusion is that how do I use this id_token to pass user information to my api"
for that confusion, you just pass your JWT token. while generating JWT token, you need to add user information in payload part in JWT token. When your api get the JWT token, just check your JWT token is correct or not by the use of secret key and if correct, you can get data. How to get is just go from that JWT Authentication for Asp.Net Web Api
ID token is sent from the authorization server as a part of OIDC protocol. The purpose of this is to authenticate the user to your client application (SPA in this case). i.e. to let your API or the application know which particular user authorized the client to access a certain resource on its behalf.
Best way to use the ID token is by decoding and verifying it using a library. This will allow you to verify the signature of the token and any other claim that is included in the token (you can add custom claims to the tokens). Validation of those claims can be used to determine identity of the user and match with the user profile in your API. You will have to check the documentation related to your IdP(auth0) to figure out how to add new claims that are used by the user profile in your API.
I am facing a custom implementation of OpenId Connect. But (there is always a but) I have some doubts:
I understand the process of obtainning an acces_token an a id_token, except the step when the OP provides an authorization_code to the client. If it is done by a redirect (using the redirect uri)
HTTP/1.1 302 Found
Location: https://client.example.org/cb?
code=SplxlOBeZQQYbYS6WxSbIA
&state=af0ifjsldkj
The end-user is able to see that authorization code? It does not expire? Imagine we catch it and we use later (some days later) Is it a security hole? Should the state be expired in the Token Endpoint?
The flow continues and we got at the client the Access_token and the id_token in the client.
How the Access_token should be used on the OP side ? It should be stored in a database? Or be self containing of the information required to validate it ?What would you recommend?
And in the client-side , both tokens should be sent in every request?
And the last doubt, if we have an Access_token the existence of an id_token is for representing authorization and authentication in separated tokens?
Extra doubts:
I know the process to obtain an access token but I have doubts of how the OP ,once generated and sent, it validates the access_token that comes with every request
How the OP knows an access token is valid? As far as I know, the OP should say that an access_token is valid/invalid. There should be some way to check it right? How it gets to know that a token represents a valid authenticated user if it is not stored in DB?
Is it a bad idea to store access_token in a cookie? Because sometimes we call to some webservices and we want to send access_token as parameter. Or there is another workaroundsolution?
How the access token should be stored in the Client , for example, in ASP.NET, in the session?
Thanks very much to all of you, I will give upvote and mark as answer as soon as you give me the explanations.
Thanks!
The end-user is able to see that authorization code?
Yes. Although, even if the authorization code can be seen, the token request requires that the client's secret be sent as well (which the browser does not see)
it does not expires? Imagine we catch it and we use later (some days later) It is a security hole? Should the state be expired in the Token Endpoint?
The spec says that the authorization code should expire. See https://www.rfc-editor.org/rfc/rfc6749#section-4.1.2.
How the Access_token should be used on the OP side ? It should be stored in a database? Or be self containing of the information required to validate it ?What would you recommend?
The access token should be stored on the OP if you want to be able to revoke the tokens. If you don't, the token will be in JWT format (self-contained)...but you should store it if you want to be able to revoke it whether it's a JWT or not.
And in the client-side , both tokens should be sent in every request?
No, just the access token.
And the last doubt, if we have an Access_token the existance of an id_token is for representing authorization and authentication in separeted tokens?
Yes, they are separate tokens for different purposes. Access token is for authorization and Id token is self contained and used to communicate to the client that the user is authenticated.
How the OP knows an access token is valid? As far as i know, the OP should say that an access_token is valid/invalid. There should be some way to check it right? How it gets to know that a token represents a valid authenticated user if it is not stored in DB?
see How to validate an OAuth 2.0 access token for a resource server? about thoughts on how the resource server should validate the access token before letting the request from the client go through.
It´s a bad idea to store access_token in a cookie? because sometimes we call to some webservices and we want to send access_token as parameter. Or there is another workaroundsolution?
I'm assuming you're using the authorization code grant flow (...from your questions). If that's the case, the reason why an authorization code is, first of all, passed back from the OP rather than the access token is so that the access token can stay hidden on the server side--away from the browser itself. With the authorization code grant flow, the access token should stay out of the browser. If you're wanting to send api requests to the resource server directly from the browser, then look into the oauth2 implicit flow (https://www.rfc-editor.org/rfc/rfc6749#section-4.2).
How the access token should be stored in the Client , for example, in ASP.NET, in the session?
In the OpenID Connect flavour of OAuth2, the access token is for offline_access (i.e. outside of an authenticated "session"). The access token could be used during the session of the user but it might be better to store the refresh token in the database so that your client app can request new access tokens whenever it needs to and as long as the refresh token is valid...even when the user's authentication is expired. The access token should be short-lived so storing it in the database is an option but not necessary.
I am following this tutorial about OAuth2.0 https://developers.google.com/youtube/v3/guides/authentication
It looks quite clear how OAuth2.0 works. But I have a bit confusion at the access token part.
After obtaining an access token for a user, your application can use
that token to submit authorized API requests on that user's behalf.
The API supports two ways to specify an access token: Specify the
access token as the value of the access_token query parameter:
www.googleapis.com/youtube/v3/videos?access_token=ACCESS_TOKEN
if someone acquired this access token during the url transferring they can access this protected resource right?
How the server know if the request is coming from the client initially requested the access token?
UPDATE:
after reading this post Are HTTPS headers encrypted? my confusion is cleared. I thought query string is not encrypted during transmission in the network.
Generally I think the consensus is that OAuth 2.0 is a server side technology and all access tokens and communication should be transmitted using SSL as the bearer tokens need to be kept as secure as possible.
Also, you need to know that there are 2 types of flows in OAuth 2.0
i) Implicit grant flow - This is the flow where the user logs in to the service provider and his browser gets the access token. Say you have X.com and Log in via Facebook. Once the user keys in his FB credentials, the access token is sent to his browser.
ii) Authorization Code flow - In this flow (consider the above situation again), facebook will pass an authorization code to the user's browser. If anyone, somehow, intercepts the authorization code there is nothing he can do. An authorization code can be exchanged for an access when passed with valid client credentials. So, when the user logs in, his browser gets an authorization code which is passed to your server at X.com. from there you would hit the code-token exchange endpoint provided by FB and get the access token returned to your server!
Authorization code flow adds another layer of security, where the access token is visible only to the client + server and not to the user agent. And as you figured out yourself, the token is passed via HTTPS.
Does oauth2RestTemplate or access token providers support validate token request?
Here is the flow:
Mobile/Web-App authenticated from third party Authentication server
and obtains Access-Token.
User tries to access a secured resources, and passed the Access-Token in the request, as expected by the protocol.
Is it possible to check this token against third-party server?
I found a bit similar here in the form of a refresh token.
Is validation request the part of the OAuth2 standard?
Thanks
No, OAuth2 doesn't enforce a specific token format or API for validating tokens. This is something that has to be decided independently between the resource server and the authorization server.
For example, the UAA project, which uses Spring Security OAuth2, uses signed JWT tokens, so the resource server can validate the contents without having to ask the authorization server directly. It also provides a /check_token endpoint, which will decode the token and verify that it has not expired.