Should the limited login store the access token for future session?
I'm transferring my iOS app from classic login to limited login. But I can't get the auto-re-login to work.
Re-login with classic works correctly as docs says. "The FBSDKLoginManager sets this token for you and when it sets currentAccessToken it also automatically writes it to a keychain cache." The app r-logins correctly.
But with limited login it seems it doesn't store the token. Should is store? The docs are unclear whether limited login should do this or not.
Best, Hu
Let's start with some points to proceed:
Limited Login mode doesn't provide you an Access Token. It provides you an Authentication Token. It's a regular JWT you can parse, but you are not able to use it for FB Graph API requests;
You can get the basic information about the user just by decoding this Authentication Token or using FB SDK right after signing in;
Currently, this token has an expiration of 1 hour, but you don't really need to refresh it every hour unless you need to get an update of the user information (for instance, to fetch a changed name, email, or a list of friends);
As you can see in the official blog post of Facebook, to refresh a token with information inside it, you need to re-authenticate a user, so call an SDK method to show FB popup. Reference: FB: Announcing expanded functionality in Limited Login
Currently, the official documentation is really unclear and has just a couple of pages related to the Limited Login mode. So if you still have any other questions, feel free to ask, I'll update the post.
My partner and I are having an issue when we use Facebook to log in to Cognito.
When we use a Facebook account that is NOT a developer, the login flow works without issue.
However, when he or I log in, we see the error message below.
Invalid Scopes: openid. This message is only shown to developers. Users of your app will ignore these permissions if present. Please read the documentation for valid permissions at: https://developers.facebook.com/docs/facebook-login/permissions
We have the following scopes set up in Cognito:
OAuth 2.0
Allowed OAuth Flows
Authorization code grant
Implicit grant
Allowed OAuth Scopes
phone
email
openid
aws.cognito.signin.user.admin
profile
NOTE: This only happens for developers specified in the Facebook Developer portal. It does not affect end users.
Any ideas what might be causing this issue?
Did openid get deprecated and replaced by something? If I remove openid from the scope, I no longer can get the IdToken from Cognito.
According to AWS documentation The Facebook scopes and attributes may vary with each API version, so we recommend testing your integration. (found in https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pools-configuring-federation-with-social-idp.html). So maybe you can check according to the api version of Facebook that you are using. In the case that you want openId (that is not the default scope for Facebook ) then, according to https://developers.facebook.com/docs/permissions/reference/ you should ask specifically for it as per this sentence If you ask for permissions other than the default profile fields, email, or pages_show_list, you must submit your app for app review so Facebook can confirm that the app uses the data in intended ways and safeguards user privacy.
First off, I'm not looking for the access token of a facebook account.
I (or my facebook messenger bot) need the access token of a linked 3rd party account.
The account was successfully linked as described here: https://developers.facebook.com/docs/messenger-platform/identity/account-linking
Slightly off topic: The first issue I noticed that does not meet the OIDC/OAuth2 specs is, that the redirect URI given to the /authorize endpoint expects a param "authorization_code" instead of "code" with the actual authorization code. Ok, good thing we do not use off-the-shelf software for the IdP, so I could mend that. Yet.
Now, I'm accustomed from the Amazon Alexa account linking to let the amazon do the token management, refreshing etc. and to deliver an 3rd party access token with every request.
But not with Facebook, it seems. As far as I managed to understand (not by the docs, but by try&error), for the Facebook Messenger the account linking is finished once they get the authorization code (and call an associated webhook).
But since I need an actual access token for every request to my bot, that's not gonna help much.
It now looks as if I have to extend my bot to be a complete, but not standardised, OAauth2/OIDC client (including token handling, refreshing etc.) with some problems:
how to check the validity of the redirect URI?
should be the same as in the initial request
how to validate the authorization_code?
keep in mind, normally this bot has no connections/access to the database of the IdP
how to link this to a specific facebook user id?
My question now is, how to cope with that behaviour when I aim to use standardised software for the OAuth/OIDC IdP? Any ideas?
Thanks in advance
Thomas
EDIT:
To clarify what is meant by "account linking": I'm not interested in the users facebook account, I want to access information of a 3rd party account (provided with my actual service) of that user.
For example a call like "How many pictures are in my tumblr account" will need the customer to link the tumblr account to this facebook messenger bot.
For comparison: this worked extremely smooth with Amazon's Alexa and Google Actions. I simply had to input the client credentials and OAuth endpoints and thats that. If the user successfully linked the 3rd party account, I get an access token with every query to my backend, as expected.
EDIT2: as pointed out by CBroe, this is not supported by Facebook. Only actually "linking" the User IDs is possible.
Recently I've been doing some research into OAuth and OpenID/OpenId Connect and it's all just left me confused as to what is best to use and what is safe.
Originally I thought you could just use OAuth2.0 to log a user in (using their ID as a way of remembering the user) but then I found out that due to how the spec of OAuth 2 works, hijacking tokens would allow a malicious user to impersonate another person. Which is why it's stated that you shouldn't use OAuth 2 as authorization.
But then I have been reading that providers as such as google and facebook have decided to go away a little from the standard and ensure that such attacks are not possible. So my question, what OAuth providers are safe to use to gather a users ID to be used to log them into my service.
Also, facebook is offering another service called facebook login. From what I can tell it's OAuth but without the impersonation issue (obviously) AND the app creator cannot do other OAuth features as such as posting on behalf of the user without getting their app reviewed by facebook. Why would I use facebook login over OAuth which gives me all those permissions without review?
Thanks a heap everone
I am playing around with the Oauth 2.0 authorization in Facebook and was wondering if the access tokens Facebook passes out ever expire. If so, is there a way to request a long-life access token?
After digging around a bit, i found this. It seems to be the answer:
Updated (11/April/2018)
The token will expire after about 60 days.
The token will be refreshed once per day, for up to 90 days, when the person using your app makes a request to Facebook's servers.
All access tokens need to be renewed every 90 days with the consent of the person using your app.
Facebook change announce (10/04/2018)
Facebook updated token expiration page (10/04/2018)
offline_access:
Enables your application to perform authorized requests on behalf of the user at any time. By default, most access tokens expire after a short time period to ensure applications only make requests on behalf of the user when the are actively using the application. This permission makes the access token returned by our OAuth endpoint long-lived.
Its a permission value requested.
http://developers.facebook.com/docs/authentication/permissions
UPDATE
offline_access permission has been removed a while ago.
https://developers.facebook.com/docs/roadmap/completed-changes/offline-access-removal/
Try this may be it will help full for you
https://graph.facebook.com/oauth/authorize?
client_id=127605460617602&
scope=offline_access,read_stream,user_photos,user_videos,publish_stream&
redirect_uri=http://www.example.com/
To get lifetime Access Token you have to use scope=offline_access
Meaning of scope=offline_access is that :-
Enables your application to perform authorized requests on behalf of
the user at any time. By default, most access tokens expire after a
short time period to ensure applications only make requests on behalf
of the user when the are actively using the application. This
permission makes the access token returned by our OAuth endpoint
long-lived.
But according to facebook future upgradation the offline_acees functionality will be deprecated for forever from the 3rd October, 2012.
and the user will be given 60 days long-lived access token and before expiration of the access token Facebook will notify or you can get your custom notification functionality fetching the expiration value from the Facebook Api..
Note that Facebook is now deprecating the offline_access permission in favor of tokens for which you can request an "upgrade" to the expiry. I'm just now dealing with this, myself, so I don't have much more to say, but this doc may help:
https://developers.facebook.com/docs/offline-access-deprecation/
I came here with the same question as the OP, but the answers suggesting the use of offline_access are raising red flags for me.
Security-wise, getting offline access to a user's Facebook account is qualitatively different and far more powerful than just using Facebook for single sign on, and should not be used lightly (unless you really need it). When a user grants this permission, "the application" can examine the user's account from anywhere at any time. I put "the application" in quotes because it's actually any tool that has the credentials -- you could script up a whole suite of tools that have nothing to do with the web server that can access whatever info the user has agreed to share to those credentials.
I would not use this feature to work around a short token lifetime; that's not its intended purpose. Indeed, token lifetime itself is a security feature. I'm still looking for details about the proper usage of these tokens (Can I persist them? How do/should I secure them? Does Facebook embed the OAuth 2.0 "refresh token" inside the main one? If not, where is it and/or how do I refresh?), but I'm pretty sure offline_access isn't the right way.
Yes, they do expire. There is an 'expires' value that is passed along with the 'access_token', and from what I can tell it's about 2 hours. I've been searching, but I don't see a way to request a longer expiration time.
since i had the same problem - see the excellent post on this topic from ben biddington, who clarified all this issues with the wrong token and the right type to send for the requests.
http://benbiddington.wordpress.com/2010/04/23/facebook-graph-api-getting-access-tokens/
You can always refresh the user's access token every time the user logs into your site through facebook.
The offline access can't guarantee you get a life-long time access token, the access token changes whenever the user revoke you application access or the user changes his/her password.
Quoted from facebook http://developers.facebook.com/docs/authentication/
Note: If the application has not requested offline_access permission, the access token is time-bounded. Time-bounded access token also get invalidated when the user logs out of Facebook. If the application has obtained offline_access permission from the user, the access token does not have an expiry. However it gets invalidated whenever the user changes his/her password.
Assume you store the user's facebook uid and access token in a users table in your database,every time the user clicks on the "Login with facebook" button, you check the login statususing facebook Javascript API, and then examine the connection status from the response,if the user has connected to your site, you can then update the access token in the table.
Hit this to exchange a short living access token for a long living/non expiring(pages) one:
https://graph.facebook.com/oauth/access_token?
client_id=APP_ID&
client_secret=APP_SECRET&
grant_type=fb_exchange_token&
fb_exchange_token=EXISTING_ACCESS_TOKEN
log into facebook account and edit your application settings(account -> application setting ->additional permission of the application which use your account). uncheck the permission (Access my data when I'm not using the application(offline_access)). Then face will book issue a new token when you log in to the application.
Basic the facebook token expires about in a hour. But you can using 'exchange' token to get a long-lived token
https://developers.facebook.com/docs/facebook-login/access-tokens
GET /oauth/access_token?
grant_type=fb_exchange_token&
client_id={app-id}&
client_secret={app-secret}&
fb_exchange_token={short-lived-token}
This is a fair few years later, but the Facebook Graph API Explorer now has a little info symbol next to the access token that allows you to access the access token tool app, and extend the API token for a couple of months. Might be helpful during development.
check the following things when you interact with facebook graph api.
1) Application connect URL should be the base of your "redirect_uri"
connect URL:- www.x-minds.org/fb/connect/
redirect_uri - www.x-minds.org/fb/connect/redirect
2) Your "redirect_uri" should be same in the both case (when you request for a verification code and request for an access_token)
redirect_uri - www.x-minds.org/fb/connect/redirect
3) you should encode the the argument when you request for an access_token
4) shouldn't pass the argument (type=client_cred) when you request for an access_token. the authorization server will issue a token without session part. we can't use this token with "me" alias in graph api. This token will have length of (40) but a token with session part will have a length of(81).
An access token without session part will work with some cases
eg: -https://graph.facebook.com/?access_token=116122545078207|EyWJJYqrdgQgV1bfueck320z7MM.
But Graph API with "me" alias will work with only token with session part.
I don't know when exactly the tokens expire, but they do, otherwise there wouldn't be an option to give offline permissions.
Anyway, sometimes requiring the user to give offline permissions is an overkill. Depending on your needs, maybe it's enough that the token remains valid as long as the website is opened in the user's browser. For this there may be a simpler solution - relogging the user in periodically using an iframe: facebook auto re-login from cookie php
Worked for me...