I'm working with Spring Boot and don't know how to design register confirmation process.
Is UUID the best choice to generate random token? I've seen that people write "no, it's not" but they don't explain why and what is better
A lot of people suggest also to avoid sending token via GET param because there is a risk that someone can steal it. They encourage to send POST requests with token in request body, but how to send POST request from email? Using ? But then my server should be able to process this request, but this type of request fits to REST application? Or meybe there is possibility to send POST request with json body from email?
I can't decide how to solve these problems.
UUID seems to be a perfectly fine solution for tokens. I don't see a problem with it.
Regarding question 2: If you have tokens, that would be used multiple times, then indeed using that token in GET requests is a really bad idea. However, for a registration confirmation, you usually only have tokens that are valid for one use. So as soon as someone used a token, you should mark this token as invalid. In that case, using it in a GET request doesn't impose any security risks. Also, the token itself should just be used to mark the user account, but it shouldn't allow automatic login of the user, once he clicked on the link. Then you should be fine.
Related
I am searching for a long time on net. But no use. Please help or try to give some ideas how to achieve this.
I once used a method:
When generating the JWT token, add a fixed parameter as the salt generated by the token. If you want to kick a user offline, you only need to regenerate the value of the salt, and then verify the salt generated in the interceptor every time Whether the token is consistent with the token passed by the client! It can be judged whether this token has been hacked.
However, this method still stores certain data on the server side, which violates its statelessness. Is there any better way to implement it?
JWT's are not a great option when you need the ability to end a user session or log them out. In order to do that you need to track some sort of state.
https://developer.okta.com/blog/2017/08/17/why-jwts-suck-as-session-tokens
You can take a hybrid option though, and use a "stateless" option (JWT validation) for less critical operations, and do some sort of a "stateful" validation for others:
https://developer.okta.com/blog/2020/08/07/spring-boot-remote-vs-local-tokens
This post might not be what you are looking for, as this is more about a client validating tokens issued from an IdP, but it shows using JWT's for "read" requests (GET, HEAD, OPTIONS), and remote validation (OAuth 2) of the token for all other requests.
I am looking for the best approach to work with the IdentityServer4 autorization code flow.
My apps system is quite ordinary: I have an MVC client, a WebAPI and the IS. I also use AJAX to request the API from the client side. So I need the access token on the client side to put it into the authorization header.
Is it good idea to store access token in the cookies?
Do I need self-contained or reference token (it is about security, I suppose)?
What is the best approach to renew when it was expired?
I thought about the two strategies:
Update access token when the first 401 status code was recieved. Can be the problem cause I send more than 1 query to the API and I need to synchronized them and recall the first one (to get result);
Every time before API calling call the MVC client method with GetTokenAsync, check the expire time and get or update and get access token. Seems cheating, cause I need to call the MVC client every time when I want to call the API.
Could you help me to find the best way?
"Is it good idea to store access token in the cookies?"
No, not with the authorization code flow. If you are using an MVC web application you should find a way to store tokens in some kind of datastore away from the browser. All the MVC application should administer is a cookie to access future MVC endpoints (that will make subsequent calls to Identity Server with the appropriate access token in the datastore).
"Do I need self-contained or reference token (it is about security, I suppose)?"
That's all up to you and what you think is best for your use cases. If you'd like to see the information in the access token and skip the extra backend call for validation then use reference tokens. Strategy 2 requires you to use self-contained tokens so that you can check the expiry.
"Could you help me to find the best way?
I don't know if I can give the "best" way, but I'd probably go with strategy 2 and use self-contained tokens.
EDIT: If you wanted to use "axios , to get data from the API" then I would suggest using the implicit flow which has no concept of a refresh token. In this case, leaving it in the cookie should be OK.
I have met a seemly easy, but actual pretty difficult situation for me, hope you can help.
WE need to provide secured rest api, but we have difference service, for example, authentication service, execution service. I now need to secure execution service.
I am using spring4 boot to boost, it seemed natural that using spring security, and then provide a customer userdetail service,but then when I start implement it, I met this big problem.
ExecutionService is not responsible for login purpose, so it won't provide a login form and consequently, it won't save token at all. What it needs to do is only checking header info, if it sees token in the header, it will use some decode algorithm to decode that token and then check if user is qualified to continue to not.
In all the posts on line regarding spring security, it all require a token storage, that means, user login first and then save token in memory, and then when user comes again, just check that token.
Can anyone help me to figure out,
1) how to use spring security to check request header info;
2) when see token in header, use a customized function to check validity of that header and then authenticate the user based on the checking result?
Thanks in advance
I have just started reading on implementing RESTful web services and creating RESTful apis. I have understood the basic concept of REST but I have been scratching my head a bit on how I will implement it securely?
Say for example, my webapp has a user login process. After successfully logging in, what else should I pass in the RESTful request to authenticate on server???
What I can think of is the following process:
user logs in (POST username/password to API)
API responds with a userkey
userkey is stored locally
When making any further requests, I include this key in request be authenticated
But here it seems that userkey is a state which I am sending to API, but REST happens to be stateless. Also this is not too secure in case of sending GET requests.
Is OAUTH the solution to my dilemma? Or some other way? Can somebody guide me on this...
Thanks
UserKey, or better call it token, is a client-side state. Your RESTful API will remain stateless since it stores this token no where.
Usually this token is a combination of some segments (username, password, login date) hashed as MD5, SHA (or any other algorythm). Whenever client calls an operation of your RESTful API, your service will compare the incoming token with an on-the-fly generated one using the same segments. If both generated tokens are equal, request gets authenticated.
There's no problem with GET or POST methods: you'll need to retrieve your token from query string or an HTTP header.
The point to secure your connection is calling your RESTful API over SSL, so your communications will have a high degree of security.
An important problem with GET and sending this token using query strings is maybe it's too long and URL length limitations would prevent you from having a lot of arguments in addition to the token itself.
In my opinion, you should go with POST verb, because you can send more data, it's more flexible and you avoid giving problematic arguments in query string, which can be bad in terms of logging, since you're going to log user names, passwords, tokens and other things, which are sensitive information that can compromise your users if a hacker steals your logs (or some unwanted person checks your log too).
OAuth is stateless - it's a token that proves that someone has authorized a client to do something - like a drivers license where the government has authorized a citizen to drive around in a car on their streets.
So - yes - use OAuth.
Disclaimer: I'm new to the REST school of thought, and I'm trying to wrap my mind around it.
So, I'm reading this page, Common REST Mistakes, and I've found I'm completely baffled by the section on sessions being irrelevant. This is what the page says:
There should be no need for a client
to "login" or "start a connection."
HTTP authentication is done
automatically on every message. Client
applications are consumers of
resources, not services. Therefore
there is nothing to log in to! Let's
say that you are booking a flight on a
REST web service. You don't create a
new "session" connection to the
service. Rather you ask the "itinerary
creator object" to create you a new
itinerary. You can start filling in
the blanks but then get some totally
different component elsewhere on the
web to fill in some other blanks.
There is no session so there is no
problem of migrating session state
between clients. There is also no
issue of "session affinity" in the
server (though there are still load
balancing issues to continue).
Okay, I get that HTTP authentication is done automatically on every message - but how? Is the username/password sent with every request? Doesn't that just increase attack surface area? I feel like I'm missing part of the puzzle.
Would it be bad to have a REST service, say, /session, that accepts a GET request, where you'd pass in a username/password as part of the request, and returns a session token if the authentication was successful, that could be then passed along with subsequent requests? Does that make sense from a REST point of view, or is that missing the point?
To be RESTful, each HTTP request should carry enough information by itself for its recipient to process it to be in complete harmony with the stateless nature of HTTP.
Okay, I get that HTTP authentication
is done automatically on every message
- but how?
Yes, the username and password is sent with every request. The common methods to do so are basic access authentication and digest access authentication. And yes, an eavesdropper can capture the user's credentials. One would thus encrypt all data sent and received using Transport Layer Security (TLS).
Would it be bad to have a REST
service, say, /session, that accepts a
GET request, where you'd pass in a
username/password as part of the
request, and returns a session token
if the authentication was successful,
that could be then passed along with
subsequent requests? Does that make
sense from a REST point of view, or is
that missing the point?
This would not be RESTful since it carries state but it is however quite common since it's a convenience for users; a user does not have to login each time.
What you describe in a "session token" is commonly referred to as a login cookie. For instance, if you try to login to your Yahoo! account there's a checkbox that says "keep me logged in for 2 weeks". This is essentially saying (in your words) "keep my session token alive for 2 weeks if I login successfully." Web browsers will send such login cookies (and possibly others) with each HTTP request you ask it to make for you.
It is not uncommon for a REST service to require authentication for every HTTP request. For example, Amazon S3 requires that every request have a signature that is derived from the user credentials, the exact request to perform, and the current time. This signature is easy to calculate on the client side, can be quickly verified by the server, and is of limited use to an attacker who intercepts it (since it is based on the current time).
Many people don't understand REST principales very clearly, using a session token doesn't mean always you're stateful, the reason to send username/password with each request is only for authentication and the same for sending a token (generated by login process) just to decide if the client has permission to request data or not, you only violate REST convetions when you use weither username/password or session tokens to decide what data to show !
instead you have to use them only for athentication (to show data or not to show data)
in your case i say YES this is RESTy, but try avoiding using native php sessions in your REST API and start generating your own hashed tokens that expire in determined periode of time!
No, it doesn't miss the point. Google's ClientLogin works in exactly this way with the notable exception that the client is instructed to go to the "/session" using a HTTP 401 response. But this doesn't create a session, it only creates a way for clients to (temporarily) authenticate themselves without passing the credentials in the clear, and for the server to control the validity of these temporary credentials as it sees fit.
Okay, I get that HTTP authentication
is done automatically on every message
- but how?
"Authorization:" HTTP header send by client. Either basic (plain text) or digest.
Would it be bad to have a REST
service, say, /session, that accepts a
GET request, where you'd pass in a
username/password as part of the
request, and returns a session token
if the authentication was successful,
that could be then passed along with
subsequent requests? Does that make
sense from a REST point of view, or is
that missing the point?
The whole idea of session is to make stateful applications using stateless protocol (HTTP) and dumb client (web browser), by maintaining the state on server's side. One of the REST principles is "Every resource is uniquely addressable using a universal syntax for use in hypermedia links". Session variables are something that cannot be accessed via URI. Truly RESTful application would maintain state on client's side, sending all the necessary variables over by HTTP, preferably in the URI.
Example: search with pagination. You'd have URL in form
http://server/search/urlencoded-search-terms/page_num
It's has a lot in common with bookmarkable URLs
I think your suggestion is OK, if you want to control the client session life time. I think that RESTful architecture encourages you to develop stateless applications. As #2pence wrote "each HTTP request should carry enough information by itself for its recipient to process it to be in complete harmony with the stateless nature of HTTP" .
However, not always that is the case, sometimes the application needs to tell when client logs-in or logs-out and to maintain resources such as locks or licenses based on this information. See my follow up question for an example of such case.