I maybe missing an important piece of jwt concept but I'm having a hard time finding info on where the server is supposed to include the generated json web token in the response and where the client is supposed to include it in the subsequent requests. Are there any rules/guidelines/best practices on that?
The JWT should be sent to the client in the response body. In the subsequent requests you've got to include an header field called Authorization with the token.
Check this link for more details.
Related
I want to be able to download a file from an API call. For argument's sake, let's say it's an automagically generated PDF file.
I have two problems:
Anchor tags can't add Authorization headers to the request, only XHR can.
XHR requests cannot download files.
My solution is to write my API with an [AllowAnonymous] end point in it, which takes the access_token as a parameter. I then validate the access token by hand and return a 401 or stream the PDF.
Is there a better solution than this or, if this is the best solution, how do I validate the access_token within the API?
This approach is totally fine.
If you want to use middleware to validate the token - it depends which middleware you are using. The plain Microsoft JWT bearer middleware has some events you can implement to retrieve the token from a query string alternatively.
The identity server token validation middleware has a TokenRetriever property which also allows you to retrieve the tokens from multiple/alternative locations.
If I have a REST API and I want to make my own authentication system is it appropriate to make an /access_token endpoint and treat it like a REST resource or should I create a seperate service for handling generation of authentication tokens etc...?
The reason I ask is this...
For a REST endpoint when you make a POST request doesn't the response want to contain a link to the resouorce so that you can GET it? What I really want to do is return the access token as part of the response of the POST request but this seems to break the paradigm of REST and would make it different from teh rest of the API, this leads me to think that the authentication should be handled by a different service.
I'll assume you're talking about the OAuth 2.0 standard, which never forces the separation between the Authorization Server and the Resource Server.
As for the other question, the access_token endpoint ought to respond to a valid POST request with a response message that contains the actual token, without this being against REST principles.
I am implementing an API that is going to be authenticated using JWT. I am curious to what are best practices on the response to the creation of the JWT. Specifically, I would like to include a payload in the response body(some user related information that I do not want to put in the payload section of the token), and send back the token in the Authorization header. Other options I see are to include the token as well as the user information in the response body, or make the client user make 2 http calls, one for the token, the other for the user information. I would like to know what is the proper way of handling this scenario.
Folks,
What is a simplest way to track consumer applications accessing RESTful API services inside department.
We do not restrict access - no authentication/authorization - open for invocation, trusted environment.
No tools like OAuth AuthZ servers or API management yet... but might be heading there at some point.
For now we thought to request consumers just to include some custom HTTP Header like X-Client-Id and log it on the server side for stats etc..
But knowing that in the future we might want to switch to more standard ways of doing things ... what would be best alternative to have to change less code in the future ?
Have the "clientId" in the Authorization: OAuth token (like access token)
Have JWT token in the Authorization header (looks too much - signing,base 64 etc for simple client id tracking ...)
Any ideas would be appreciated
We recently implemented this for one of our REST platforms and we used a combination of BOTH the points you mentioned, meaning Authorization header & JWT token. Although, JWT is ONLY for authentication and GETTING an access_token (oauth token) which is later used with calling actual resource apis. I will discuss how we handled this situation and you can decide on how you want to implement it.
1) Authentication
Client sends a JWT to your authentication service (/api/oauth2/auth). (If you want more reading on JWT, you can read here and here of how JWT is implemented by google and how you can use spring-security-jwt libary to handle all the signing and encrypting/decrypting). You get the "clientId" out of JWT after decrypting and verifying the signature and after server does all the authentication, you respond back with a 'refresh_token' and an 'access_token'. Server will save the access_token as well and map it to the clientId so that when client makes requests using access_token, you can know which client is making the request. The access_token expires in some time (ideally in an hour) and when it expires, the client uses the 'refresh_token' to get a new access token by posting refresh_token to some refresh token url (/api/oauth2/auth/token)
2) Authorization
Client takes the 'access_token' and uses the access token to make all the subsequent requests on all other apis (/api/*). Ideally, the access_token is sent as a part of the "Authorization" header. Server uses request filters (if you are using JAX-RS, you can use something like ContainerFilterRequest to add filters to specific url patterns and intercept them) to filter EACH request and parse out the Authorization header value. You will get the access_token from the header and from the access_token you can get the clientId that you mapped in step 1). You can do other authorization logic in the security filter and if everything goes through, you can use this information to LOG that clientId and the request that the client made.
This way you can kill 2 birds with one stone : Implement a security layer & log the information about customers (what calls they are making, how many time etc. etc.). In case you don't want to implement security filter just yet (as you mentioned it might be in the future), for now, the clients can just pass on the "clientId" (base64encoded or not, upto you) as a part of "Authorization" header. If all the calls are from a "trusted" network, it should be ok, although not as secure. This way, when you ACTUALLY implement a JWT and Oauth based security layer, all you have to do is change your ContainerFilterRequest logic to parse out access_token instead of client id (as mentioned in step # 2).
I hope this helps ! For more information on security filters you can have a look at this answer: Basic Authentication of a resource in Dropwizard. It says dropwizard, but it mostly talks about JAX-RS.
To implement full AuthN/AuthZ layer for consumer tracking would be an overkill for now.
We thought to use either to Authorzation header to pass custom client_id token:
Authorization: Custom <Client_Id>
or to use some limited version of JWT (no signatures as there no intent to validate them)
as access token
Authorization: JWT <JWT>
Where JWT could be:
{"alg":"none","typ":"JWT"}
{
"iss":"Client_ID",
"aud": REST Service URI,
"iat":1328550785
}
I do not see description of access_token format in the specification https://datatracker.ietf.org/doc/html/rfc6749#section-1.4
Are there any contraints to use JWT as access token?
including a CSRF prevention token in POST requests and validating it on the server by overriding DefaultRequestTransport and RequestFactoryServlet seems to be simple enough.
However, I have one remaining issue: How can I generate the token and get it to the client the first place?
It is quite possible, ney likely, that I have missed something obvious. I am assuming that I need to create the token when the session is created on the server, store it in the session and pass it to the client.
The client then stores the token in a cookie and passes the token in request headers from that point onwards.
Is there a filter of some sort which I can use to provide the tokens?
If you were using RPC, you can read this document, it has example code for implementing it.
For RF, this question could be helpful.
The server generates a random token on the first request and typically includes it in the download of the script.