I wanted to know if the length of access token is constant all the time. I'm using OAuth 2 authentication type and want to get the access token from the final redirect URI generated.
I'm trying to do substring of URI to get the access token and want to know if the length is constant.
Related
I have been searching lately about refresh tokens and access tokens with rotation and something hit me.
Why not just use one token instead of access token and refresh token? Include in that token payload (claims) a validation date, and make the validation period very low ( just like access tokens ) and the expiration date very high ( just like refresh tokens ).
If the validation date exceeds the date on the server but did not expired, the server issues a new token and invalidate the old one ( by whatever mean like a blacklist of tokens etc just like when AT expires and new ones are issued using Refresh token) , and if the token expires then the server simply reject the request and ask for authorization ( just like when refresh tokens expires ).
If this approach works then why do we use 2 tokens which makes the dev process harder ?
I think you are forgetting something.
Refresh tokens are stored on the server. Access tokens are not. Access tokens are self contained. This is why they are referred to as bearer tokens. The bearer of the token is granted access.
Which means if an access token is stolen by a malicious party, they can be used as long it has not expired. Access tokens are considers safe because of their limited life span.
In order to use a refresh token in order to request a new access token. You need to have the client id, client secrete that was used to cerate it. You also need to be able to listen to one of the valid redirect uri's for the refresh token response.
An integration for the app I'm working on requires that a user be logged in via a redirect. So the plan is to have a single use token as url param, then once they get redirected and the token is verified I will create a session for them with cookies. Unfortunately putting the token in the headers is not an option here. I was thinking of ways to accomplish this without having to make a new table for either whitelisting or blacklisting tokens, and came up with this:
Create a token who's payload includes an expiration time, the users id, and the users last sign in datetime. Then encode that token with a secret.
Then to validate the token after the redirect, it first gets decoded using the secret. Then the expiration time is checked. Lastly, I get the user's last sign in datetime from the database, and check that it matches the one in the token payload. If all checks pass, then the user is signed in, and a session cookie is set for them.
Mainly I'm looking for feedback about security. Thanks!
I was trying to find the token on a login page. I've already searched on page source but it'isnt here. I'd like to know the practices for passing an access token and then the way to find it
The best way for token authentication is to pass it along with the request headers.
Normally u can find the tokens in the cookies with the respective key name
Let's consider this use case:
1) I call my API login endpoint with username and password and get my Auth token that I add to every consecutive request to the header as Authorization: Bearer <token>.
2) I call /current-user endpoint with no params, only with Authorization header. Server authorizes user using token and gets user's id from that token. Then he finds the user by id in database and returns it's data.
My question is, whether this approach isn't insecure. I'm wondering, what if I was an attacker and was calling /current-user endpoint using randomly generated tokens. Once I occasionally matched real token, the server would return me other user's data.
Isn't it necessary to store user id on client along with token and call requests using both? Eg. /user?id=<stored user id> with Authorization header and get rid of /current-user endpoint? After that some kind of ACL on server would determine, whether used token has allowed access to user with passed user id.
(I also found there are JWT tokens but I see the same problem there. As an attacker I would somehow manage to guess other user's token and server would return me his data)
For security purposes, it is normally assumed that the user id is known to the attacker anyway. For example, if the attacker already has or knows a legitimate account, she might be able to guess how other user ids are assigned.
Also, if your token is long enough and totally random, it doesn't really make any difference.
Look at it this way: let's say your token has length n, your user id has length m. Without the user id, the attacker has to guess n characters, with it included she has to guess n+m characters. If your n is high enough, you don't need those extra characters. Keep in mind that the effective length of the user id might be much shorter than its apparent length if your user ids aren't completely random, so the m added might actually be really small.
Is it possible for you to use digitally signed tokens? You could basically encrypt the token with the client's (or user's) private key and then encrypt the package along with plaintext userid again with the server's public key. That way only the server can decrypt the package and once decrypted, it knows who the user is. It can then use the public key associated with that userid to decrypt to the package and get the token.
As you havent provided much info on the application and the speed of authentication required or technologies you are using, it is difficult to provide any more info.
I was comparing cookie vs token authentication. I'm fairly familiar with cookie auth, but I needed to understand how token auth works.
From what I understand
User Logins in with Username and Password
server gets data and checks if Username and Password match
If match, generates token using alg like SHA256?
sends token to user
user sends request w/ token and other data to access restricted data?
server uses other data and hash method to check against token?
What I'm confused by is 3, 5, and 6, the token generation part.
For 3, what data do you put to hash, is it just a hash or is there
more to the process?
For 5, what if any other data is sent with the token?
For 6, how is the data sent used to validate the token?
How can you tell if the token has expired?
For 3, what data do you put to hash, is it just a hash or is there more to the process?
Whatever you like really. The implementation details are only of your concern. Basically, the token is a random string (encrypted, hashed or not)...again, it's up to you how you want to implement it. But, always make sure a token is unique across the system and that the system can use it to effectively identifier a user and its scope
For 5, what if any other data is sent with the token?
I'm not too sure what else you need to send, but usually you don't have to send anything else because of what I mentioned above...an access token must describe a user (or device, or whatever) and its scope within the system. So, why would you bother sending additional information?
For 6, how is the data sent used to validate the token?
And again, it's up to you. Other data could be the user's email address or the user id and then your system can match the userid (or email) with the access token. However, this is NOT mandatory, you can implement it whichever way you want to.
How can you tell if the token has expired?
Well, if your system issues temporary access token, hopefully it will be keeping track of when the access token was created and then determine if the access token has expired based on the creation. That's from the server side. For example, in its simplest form, you could have a database table that stores access tokens with the following columns:
Access Token: unique string
UserId: the related user id
DateCreated: UTC time
That's all you need to make it work, of course, usually you will want to provide stronger security and this table will be much bigger.