I managed to login with google plus, but after authenticating, I'm not sure which of the values is the unique value to authenticate the user.
After authenticating, I see a response with fields like:
access_token, code, id_token, but I'm not sure which to use?
access_token: you use this to make API calls as the user who has just signed in - e.g. to retrieve profile information. This is valid for 1 hour.
id_token: this is a special signed blob which contains the user id of the signed in user, and the client ID of you application, can be used to identify the user. This is valid for one hour also.
code: you can send this to a server to exchange for an access token (to allow the server to make calls). This is valid for a few minutes.
In general you will use the access token to retrieve the user's name and photo as a next step: https://developers.google.com/+/web/people/#retrieve_profile_information
Related
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 want to create a login system using JWT and have these questions:
1- My client login and I generate a token for him/her and store the token in local storage. Now If somebody else copies this token from local storage of this person browser and paste in his/her (I mean hacker) browser local storage, this hacker will able to log in? If yes, is that safe?
2- I put user Id in the token that I generated On login function. On each request that is sending to the backend, I decode token and find userId in it. Now should I compare this user id by anything? Example checking that is there any session by this user ID in backend or even checking the user Id by DB?
3- should I put an expiration time for JWT token on the local store?
1 - It's safe to store these in localStorage. It is worth checking out how to protect against Cross site scripting attacks; this is particularly true for high security environments. Users copying and pasting is probably an unlikely attack, and, if the user has physical access to do the copy and paster, there are probably other 'vulnerabilities' like just using the browser's stored passwords.
2 - The JWT encrypts the user id included in the claim. A user can't change this claim and keep it valid (assuming a strong key), so no need to check this elsewhere.
3 - Yep! Since the JWT has a claim (like the user roles) in it, you don't want those to be valid for forever. Also, you want to have a way to ensure that users re-verify their identify (ie. log in again) just in case something goes wrong/a token is stolen. When you put an expiration on the token, you force this.
I want to allow/prevent access of users to certain actions based on their role (admin, user, maybe something else) and id (users can only modify resources they own).
I do not want to load user profile in every API call, I want this information passed in request headers somehow.
I am considering two approaches:
User's access token contains both the required user information and time period (aes encrypted). The token is passed in Authorization header in every request. Server decrypts the token and gets all the information from it.
User's access token has the same information hashed (with HMAC). Authorization header contains both the token and the required user information (ID, role, maybe username). Server hashes user's information together with the current period using the same secret and compares with the passed token. If they are equal the access is granted.
Which approach is more secure (I feel the 2nd) and more common (probably the 1st)?
If you think the approach 2 is better, is it maybe better to pass user's information in a separate header?
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.
I am building a service in which users do not have to create an account to sign up, but use Google account as exactly does Stackoverflow.com
My Question is there is any unique information of an user in OAuth2 which never change, so I can use it as user id in my database.
After looking through Google OAuth2 API, I've ended up that all tokens are arbitrary every time session is established.
I would like to know how such sites as Stackoverflow extract the user information to sign up.
After getting the initial access token use the tokeninfo endpoint to get user_id.
https://www.googleapis.com/oauth2/v1/tokeninfo?access_token=" +
Uri.EscapeDataString(response.AccessToken))