I'm building my first app using react-native and expo.
When I log in into my app using Facebook Auth and my personal account, I receive an access token; then I save it locally in the device using SecureStore, provided by expo.
If I try to log out, and then log in another time, I receive a new access token, different from the first one.
But if I try to make a get request, for example just to obtain the name of my facebook account, using the old access token...I can do it!
I wrongly thought that every time the same user try to access into the app using facebook auth, facebook gives the same access token given in the previous session (if it isn't expired or invalidated yet).
So... What I have to do? Just locally override the old token with the new token? Or should I invalidate the old token because of it is still valid (and if so, how could I do this)?
Access Tokens are not valid forever: Basic User and Page Tokens are valid for 2 hours so you do not have to invalidate them on your own. Extended Tokens are valid for 60 days but I assume you do not use those. Just override the Token with the new one, you do not need to worry about old Tokens.
Source: https://developers.facebook.com/docs/facebook-login/access-tokens/#termtokens
Related
I am trying to integrate the Google sign in sdk into my site.
I have already added the GSI button to my site and on clicking it, google sends the IDtoken containing the user info to my oauth endpoint.
Using this token, I can now create a new user account.
So far so good.But I am not sure what I am to do from here.
Should I put this IDtoken into a http_only and secure, cookie so that all authz server requests will contain the userid?
I am seeing lots of cookie and local storage based data has been been added to my sites jar. Am I supposed to use them in any way?
What do I need to do after the token expires after 1 hr? Do I need to have my users login yet again? I did not get any refresh token along with the idtoken. Do I even need to handle the refresh token or is the gsi sdk supposed to take care of all that for me?
Another part which is not clear is what do I get from using the Google sign in button/sdk vs the general Oauth-openid flow.
This is a summary of an issue I filed directly with expo (it ws closed but I have asked for it to be reopened):
This issue happens whether using AuthSession.startAsync,
AppAuth.authAsync or WebBrowser.openAuthSessionAsync on iOS in
local development and published release (expo managed). Haven't tried
on standalone build yet.
Steps to Reproduce
user presses 'sign in' button, (app calls one of the above methods to kick start authentication session with a Salesforce oauth provider)
user enters credentials successfully
app goes through oauth redirects and returns user to our app and we get our access token.
user presses 'sign out' button (app calls revoke endpoint for token, then calls server endpoint to delete any browser cookie sessions for given account reference)
app navigates to sign in screen
user presses 'sign in' again (app calls the same method from above to start the authentication session with Salesforce oauth provider again)
instead of opening the sign in page, the app redirects itself back with an access token as if the user had successfully entered their credentials, even though any cookies/session data the browser stores should be invalid and necessitate a sign in.
Expected Behaviour
steps 1 - 5 are all as expected. Step six should be
app redirects to Salesforce oauth provider sign in page, in unauthenticated state (ie no cookie or session data that was previously stored is still valid)
user is required to re-enter their credentials
oauth flow takes over and redirects the user into the app if the credentials were correct.
Actual Behavior
as per initial steps where the user is not even asked to enter their credentials (step 6):
instead of opening the sign in page, the app redirects itself back with an access token as if the user had successfully entered their credentials, even though any cookies/session data the browser stores should be invalid and necessitate a sign in.
Reproducible Demo
The code is in a private repo so I can't share details of it, but it's a very standard oauth flow, and seeing it's happening in all three of the method calls from the top suggests to me that it may be due to something in the WebBrowser.openAuthSessionAsync implementation. I have seen on the apple developer docs that SFAuthenticationSession has been deprecated in favour of ASWebAuthenticationSession. My understanding is that this (SFAuthenticationSession) is the browser used by expo's WebBrowser and the wrappers mentioned above (AppAuth and AuthSession) for the oauth interactions. I also see that it mentions it's for a one-time login, which perhaps explains why it would hold onto any session data and jump to the conclusion of re-authenticating without directly seeking credentials from the user, but it seems unhelpful to store a cookie without validating it, which is what appears to be the end result.
Notes
Essentially this is making it impossible for a user to sign out of our app, because the system browser, that we don't have control over, is keeping track of their authentication despite the session value no longer being valid against the server.
I've seen other people looking to find ways to clear cookies from the system browser, which may be what this issue relates to, though it doesn't appear to be possible to access the auth session's browser cookies in any way. This comment on a GitHub issue is exactly what I'm experiencing and need to find a solution to.
I would like users to be able to sign out, and then when they sign back in again they should have to enter their credentials again. Does anyone have any thoughts as to how this might be possible?
On iOS, it's now possible to pass in the following config to WebBrowser.openAuthSessionAsync to essentially treat it as incognito and ensure it doesn't retain any cookies. The effect is that the user will have to re-authenticate each time (even if there session is still active). I'm not aware of a similar approach for Android, however.
Code
const browserOptions = {
preferEphemeralSession: true
}
result = await WebBrowser.openAuthSessionAsync(authUrl, redirect, browserOptions)
We have an Instagram client id and client secret, and already have gone through the documentation of generating access tokens which requires redirect url.
Note that we also have disabled the implicit OAuth flow.
Now we already have generated the access token using URL below (for authenticated user, it returns the access token appended in the response URL)
https://api.instagram.com/oauth/authorize/?client_id={client_Id}&redirect_uri={redirect_url}&response_type=token&scope=public_content
Can this token be stored in the database / configuration files and re-used for any new Instagram API requests? e.g.
https://api.instagram.com/v1/users/{user_id}/media/recent/?access_token={reusable_access_token}
Based on the official documentation, we understand that the access token can become invalid at any point of time, we would like to know if there are any specific scenarios which leads to invalidation of the access token?
What would be the best way to generate token once and use it for each API request? We definitely do not want users to enter credentials manually to generate tokens.
Unfortunately at that point it's not possible:/ Instagram doesn't provide refreshing access token in the background.
User needs to login with their credentials, so you can obtain new access token. Some kind of workaround (not nice, but it's working) is to watch for error type OAuthAccessTokenException and notify the user via e-mail about such fact. He will have to login once more, so you can get fresh and working access token.
Also, please keep in mind that access tokens has a pretty long life span. It doesn't expire after a day or two, unless Instagram API has some issues (like just now OAuth - unable to exchange code to access token for some users).
Otherwise it works really well.
However it would be super nice if Instagram could add to their API renewal option in the background for access tokens for users that autorised your app, but their token expired:)
I am trying to implement a login for my mobile app to my backend. I previously used to use a method that required hashing on mobile site and backend site. The password would be hashed saved on the mobile site and be included in the hash. If hashes on mobile side and backend side would be equal, the request would be valid.
However I wanted to add Facebook login to my login system so I kinda find out it was not gonna work the way I had built it before. I came to the conclusion that I probably have to change the entire method to token login.
What I have currently functioning is Facebook button on mobile side, this creates for me a Facebook userid and Facebook access token. I send both these values to my backend and use a Facebook graph call to retrieve the facebookid from the access token. if both the Facebook userids are equal. I either register the user or log him in.
This is where I get stuck. I now want to generate my own token to send back to the mobile side, because I have custom login (email+password) (Facebook is just an option). So I think using my own auth token for both ways is the best.
I have a few questions about this token:
What should the token exist of?
Do I need to save this token on the mobile (not hashed?)
What is the best way to built in expiring time and automatic refresh token
What I can't really understand is the security of this authentication method. Sending a token over a request that gives you access to user information is just as bad as a plain password I think? Is SSL connection simply enough?
I understand these are a lot of question in one but I hope someone can give me a clear explanation.
Thank you
You can try JWT (JSON web token), it's really simple. The idea its, when you do the login, the servers return you the JWT and you simply have to save it in your mobile app. Then you have to pass it as a header (assuming you are developing for Android):
request = new HttpGet();
request.addHeader("Authorization", "Bearer " + Global.loginData.jwt);
I am building an integration component using a graphical framework who has a pre-build OAuth2 connector.
This framework required following fields for OAuth v2:
Grant type
Scope
Auth Server URL
Client Id
Client Secret
Access Token
Refresh token
I need to get data from Google Analytics API, so I went to Google Dev Console
(https://console.developers.google.com/project/927890000889/apiui/credential). I generated a 'Client ID for web application'. From the parameter of this object I was able to fill some of the parameters above
Grant type : 'authorisation_code'
Client Id : 'RANDOMCHARSam5o37nsiu730d.apps.googleusercontent.com'
Client Secret : 'RANDOMCHARSiSwBA5OH5qYLUa'
Then using Google Oauth Playground (https://developers.google.com/oauthplayground) I was able to fill the missing bits
Scope : 'https://www.googleapis.com/oauth/analytics'
Auth Server URL : 'https://accounts.google.com/o/oauth2/auth'
Access Token : 'RANDOMCHARSQAQv4HRF5-JsQEzUS61lj2YremyCocv0PQ4-agpzJe'
Refresh token : 'RANDOMCHARSLPJnL4FPaDc2KP6V8kCzjjHO2Kj4Np_3X0'
Everything works fine, I am authorised to access and I get data from Google Analytics, but just for a while, after few minutes if I retry I receive an authorisation failure error.
I believe that the problem is related to the expiration of the Access Token, but I don't know how to solve that.
Worth to mention that this activity it's batch (no human interaction), so nobody can request a new access token.
The integration framework is not extensible (I cannot write code to renew the code) so I believe there's a way to get a access token that never expire or some other mechanism to achieve the same result.
Bottom line, I am not sure if I approached the requirement correctly since the beginning (Client ID for web application).
Any help is much appreciated,
Giovanni
Access tokens typically expire after 60 minutes. If you have a refresh token you can use the refresh token to get a new (valid) access token.
This doc explains how to do that:
https://developers.google.com/accounts/docs/OAuth2WebServer#refresh
To answer your overarching question, yes, you are approaching everything correctly. All you need to do is handle the case where the access token has expired by refreshing it. Also, when you originally requested the access token the response should tell you how long it's valid for, so you should only refresh that token if it's expired.
You can use Refresh tokens to make it more long used.
The Google Auth server issued Refresh tokens never expire,
A token might stop working for one of these reasons:
The user has revoked access.
The token has not been used for six months.
The user changed passwords and the token contains Gmail scopes.
The user account has exceeded a certain number of token requests. There is currently a limit of 50 refresh tokens per user account
per client.If the limit is reached, creating a new token automatically invalidates the oldest token without warning.
This limit does not apply to service accounts.
from: https://developers.google.com/identity/protocols/OAuth2