I am trying to write a client in spring which would invoke a REST api secured by OAuth2.
I have the following which i can use to get a token from Auth Server and then invoke a resource server.
Client ID, Client Secret, Username, Password and Access Token URL(URL to fetch the token from) , and Resource URL.
How do i write a client in spring boot which has above info so i could invoke the resource server URL to fetch my resource or do a POST.
After i get the access token which would have a Time To Live in ms(TTL), how do i cache it so i do not have to generate the token for every request. Is it good to cache the token ?
You can use declarative rest client - feign spring-cloud-starter-openfeign
for consuming the service and for cacheing the Spring cache to cache the access token.
Tip : call the access token and cache it and resume it in the subsequent calls.
Once the endpoint throws unauthroized exception or the token becomes invalid, then the retry mechanism in the feign client can make another call. To implement the retry, you need to have "spring-retry" as one of the dependency.
If you are using JWT tokens, the time-to-live is encoded in the token.
You can store it in local storage
You can store it as a cookie
You can store it in the browser session
You can implement an arbitrary way of storing your token
Where you supply your token is up to you.
It could be at any stage of communication (request parameter, header, on-demand).
I would suggest to do it like below using CloseableHttpClient
Put details like clientID, user creds, access token in the header of the Http call
Use CloseableHttpClient class -> execute method and pass the header along with URL.
Parse the response and extract the details
Store the retrieved token with either using Spring cache as mentioned by #Sivaraj or you can use a table to store the value along with a timestamp and fetch this value for next calls.
Related
I have a controller method that has an argument OAuth2AuthorizedClient with annotation #RegisteredOAuth2AuthorizedClient.
ResponseEntity<String> getFoo(
#RegisteredOAuth2AuthorizedClient("custom") OAuth2AuthorizedClient client) {
OAuth2AccessToken token = client.getAccessToken();
....
}
In order to resolve this, spring look for OAuth token on OAuth2AuthorizedClientService which actually stores the previously authenticated tokens in memory.
Now, I have a scenario where I obtain JWT token from OAuth server outside of this spring resource server, and trying to authenticate this server by passing token using Authorization header.
But when spring trying to resolve OAuth2AuthorizedClient it is looking for token in-memory with the principle of JWT (which will obviously not found since token is not obtained on this server). Hence send new login redirection for new token.
Overall question would be, is it possible to resolve OAuth2AuthorizedClient with the JWT token (obtained ourside of the server) passed in Authorization header?
I am consuming a secured Restful Service that grants access through Basic Auth (Username and Password). I have successfully accessed the API service and consumed its API; however, I am still confused as to what is the right way to implement HTTP headers with Basic Auth. I would assume I should authenticate only once, but the way I have constructed my code, it looks like I need to authenticate API with each service method I create.
Should I create a helper method with the authentication and call it on each service?
If you are using Basic Auth you need to always include credentials with your request. In case of OAuth, tokens have expiry. In this case, a token caching mechanism for the duration of a little bit less than the expiration duration would do the trick.
The Basic Auth is a kind of no status authentication. That means the server wouldn't record. Every time you need to provide username and password with your request. Each request is equal to the Server.
For another authentication called OAuth, the first time you request with username and password, the server will return a token to the frontend, which has an expiration period. So, you request every time with the token through the filter, where checks the expiry of the token. If it's not expired, using the same token for requests, otherwise, making a request to get another token.
I have a spring boot application that is using OAuth2 and it works good. The problem is that the access token and the refresh tokens is accessible with a GET request which making the tokens to be exposed and i want to switch it so the token will be stored in a cookie (httpOnly of-course) and will be accessible by the server side only.
I've searched the internet to find some example or explanation on how to do that but found nothing so far.
The only thing I've managed to do is to override the AuthenticationSuccessHandler the onAuthenticationSuccess() method and store the tokens in a cookie but it is only half work the question is how to override Spring's OAuth2 to use this cookie instead reading the token from the request headers?
And how to override the default access (GET request) so the tokens will be stored only in a cookie only?
Thanks in advance!
As restful service stateless, it don't maintain any interaction of user, so i want to know if multiple user accessing same restful service, then how restful service identify which user interact with which method ? and is it possible to make restful service as stateful ?
Which user:
By using a shared secret (a line of chars), created on the server, and returned with every next request.
It's "saved" in a cookie and returned by the client, using either a cookie or a HTTP(S) header.
Which method:
This depends on the framework you use. But eventually it comes down to mapping URI's to your methods.
and is it possible to make restful service as stateful ?
You can make stateful apps, then they are not restful. A restful app is stateless. That's the definition, so you can make stateful apps, but you can never create a stateful rest-app, as rest is stateless.
tl;dr
The client must store its own session state and pass it around to the server in each request.
The stateless constraint
The stateless constraint of the REST architectural style is define as follows:
5.1.3 Stateless
[...] each request from client to server must contain all of the information necessary to understand the request, and cannot take advantage of any stored context on the server. Session state is therefore kept entirely on the client. [...]
Authentication
If the client requests protected resources that require authentication, every request must contain all necessary data to be properly authenticated/authorized. See this quote from the RFC 7235:
HTTP authentication is presumed to be stateless: all of the information necessary to authenticate a request MUST be provided in the request, rather than be dependent on the server remembering prior requests.
And authentication data should belong to the standard HTTP Authorization header. From the RFC 7235:
4.2. Authorization
The Authorization header field allows a user agent to authenticate itself with an origin server -- usually, but not necessarily, after receiving a 401 (Unauthorized) response. Its value consists of credentials containing the authentication information of the user agent for the realm of the resource being requested. [...]
The name of this HTTP header is unfortunate because it carries authentication instead of authorization data.
For authentication, you could use the Basic HTTP Authentication scheme, which transmits credentials as username and password pairs, encoded using Base64:
Authorization: Basic <credentials>
If you don't want to send the username and password in each request, the username and password could be exchanged for a token (such as JWT) that is sent in each request. A JWT token can contain the username, an expiration date and any other metadata that may be relevant for your application:
Authorization: Bearer <token>
See this answer for more details.
According to my point of view Restful web service make as a stateless.it's architectural style which have set of constraints and properties so stateless is its properties we cannot change its properties so its doesn't mean that restful service is stateful .
we can mapped URI's to your method then restful know which user is calling which method.
I'm developing a web application (Back end : JAVA/ stateless REST API) (Front end : Angular) which eventually be placed inside another web application.(let's say parent app).
The parent app which is session based handles authentication by username/password and create token for each user. Once a user is able to login the parent application he or she should also able to access my application. It is good to mention the token can also be used to retrieve user data by a SOAP call from my application.
My idea is to get this token with my front end component and send it to my REST Api. I'm going to keep those tokens inside a concurrent hash map and for each call coming from FE I'll check the token on BE for authorization. I wonder if it is a correct approach?
When the parent app's session expires or the user logs out is the token invalidated?
If yes, how does your app know the token was invalidated? Is that the check the token on the BE? (which would need to be done for every request)
If a shared session is not an option then your approach is reasonable.
Also, for security the REST calls should always be HTTPS (refuse the request if not), and consider passing the token in a header instead of on the URL as a query parameter.