It seems there is a problem in pulling the Page insights data I'm admin of using my App access token.
I have been able to fetch my user and post related data but I'm geeting an 'OAuth Exception' (Invalid query) when I try to find my page insights.
The same query works wonderfully when I try accessing insights using the 'User Access Token' generated by Graph API.
As I want to generate an extended token and then pullung page-insights, that's why I'm try accessing data using App Access token.
Please let me know what's wrong.
Page insights simply aren't supposed to work with the app access token; you need to use a page access token, or a user access token from a page admin that has granted permission.
Go get yourself an extended page access token, as described here: https://developers.facebook.com/docs/facebook-login/access-tokens/expiration-and-extension
Those do not have a default expiry. (Although they may become invalid for other reasons, f.e. if the password of the user account that was used to request it gets changed.)
Related
I am using React with Django Rest Framework as backend with proper permissions. I am using token authentication and axios to make queries to the django api. Firstly, I can do a login with credentials in my React interface, and I store access token in the local storage. After about 5 minutes, if I make a new query I get an error from django telling me "access deny". I can catch that kind of error and send the user to the login page again. But here I have two questions:
1- What should I do to refresh access token whereas the user is working? I have refresh token but I do not know what to do.
2- If I get rid of the first problem. I want the application goes automatically to login page after 5 minutes without any user activity. I mean, I want to go to login page without the need of an explicit click on all the possible options. Some kind of background query to django to detect expiration, so that I can redirect to login page.
Thank you in advanced.
I have 3 applications:
An IdentityServer4 API which provides Google authentication and also provides an access token to authorize the resource API.
A simple Resource API which provides some data from DB.
A simple Client in React which have 4 buttons:
Login, for Google auth
Logout
Get data - a simple request with the access token to the Resource API and gets the data from Db
Get user data - returns user profile and token (for debug purpose)
I didn't put any sample code because my problem is not code related, it's knowledge that I'm missing and I ask for guidance.
The workflow is working just fine: the user press the Login button, it is redirected to IdentityServer4 API for Google Auth. From there it is redirected to a Callback Page from the Client and from there to the Index page. I receive the user data and the token, I can request data from the Resource API and it's working.
My problem is: How do I give a Role to the Google Users ?
I don't have users saved in DB. I want three types of Users: SuperAdmin, Admin, Viewer and each of these roles have limited Endpoints which can access.
For limiting their access I saw that I can use Claims-based authorization or Role-based authorization.
So, my question is how ca I give a Google User who wants to login in my app, a specific Claim/Role ? What is the workflow ? I must save it first in DB ? Or there exists a service from Google where I can add an email address and select a Role for that address ?
Thank you very much !
After you get the response from Google in your callback you can handle the user and do what ever you want to do with it. Below are the some typical tasks that you can do in callback that I took from documentation page of identityserver4 link:
Handling the callback and signing in the user
On the callback page your typical tasks are:
inspect the identity returned by the external provider.
make a decision how you want to deal with that user. This might be
different based on the fact if this is a new user or a returning
user.
new users might need additional steps and UI before they are allowed
in.
probably create a new internal user account that is linked to the
external provider.
store the external claims that you want to keep.
delete the temporary cookie
sign-in the user
What I would do is creating an new internal user account that is linked to the external provider and add a role to that user.
If you don't want to save users in db, you can add an extra claim to user in callback method and use that claim in token. and i think this link will help with that.
I have an implementation of IdentityServer4 which connects with Azure AD for authentication (OIDC). In the callback method, using the IdentityServertools, I am generating the access_token and redirecting the user to SPA with the same. The SPA then stores the access_token into localstorage and uses it for authentication.
Normally, when my SPA app hits the token endpoint of the IdentityServer4, it gives access_token and refresh_token and then uses refresh_token to re-authenticate a returning user.
In this case of SSO with Azure AD, do I need to generate refresh_token manually? If yes, I can build on top of default implementation and that's not the problem (However, the docs suggest against of changing the IRefreshTokenService implementation or building something from scratch)
My real question is, is there a need of refresh_token here? Because refresh_tokens are stored in DB and never get's deleted and after sometime, these refresh_tokens table will swell (right now it already has 80k rows). The user is expected to click on a small tile inside SAP's Successfactor - that will open the signin/consent screen of Azure or will directly take the user to the main page where zhe will just answer a question and done. So it's hardly 2-3 mins business. So I can continue to generate access_tokens from my IdentityServer4 for every click as I don't expect the user to stay authenticated in the browser if zhe has logged out from SAP's Successfactor (or any other app linked with Azure).
Please advise, if I should generate refresh_token? Is it a good architecture?
Access token is used to prove the request is allowed to access the resource(such as api from ms or your custom api) and refresh token is used to refresh access token to make sure the access token isn't expired. Access token will expire in an hour by default and refresh token has 90 days.
At this point, we can easily find the refresh token is designed for some special scenarios because the expired time for refresh token is much longer than access token's expired time, but we can also generate a new access token in other way such as using msal or sign in again.
As you said in the question, you can generate an access token by one click and you don't expect users to stay authenticated for a long time. So I think it's unnecessary for you to use refresh token.
I am building a glass app using the PHP sample app as reference.
To my understanding, the glass app is a web app which is user facing. When the user visit the web app, they will authorize the web app (using oauth2) to access their resources, and once authorization succeeded the web app will get an access token, which is then saved in a sqlite database (there's this store_credentials() function which stores the access token).
So if I have 100 users who visit the web app and register, the database will hold 100 access tokens for these users. Let's say I have some backend code which pull from a RSS feed every hour, and whenever I find there's a new story I will push it to all registered users. Let's say I have a cron job which does this, when when this job is triggered, I will find all the access tokens in the database and use them to make mirror API calls to insert cards. But what if some of the access token is expired when I am trying to make the mirror API call? It seems I will need to ask user to re-authorized, but at this point I am not interacting with the user. If I have a refresh token, I may be able to call oauth again to get a new access token.
Thanks.
You pretty much answered your own question - when you request permission using OAuth, you should also request "offline" access. The first time you do this for each user it will give you a refresh token along with your access token, and you should store both. If you did not request offline access initially, you will need to revoke the tokens that have been granted and re-grant them with offline access.
If the sample app you're referring to is the one at https://github.com/googleglass/mirror-quickstart-php, all this should be done for you already with the libraries included. The credentials returned from $client->getAccessToken() in oauth2callback.php should include both the access and refresh tokens, and these are saved in that same file by calling store_credentials(). The client libraries should check if the access token has expired and, if so, it gets a new one with the refresh token before making the call.
You may want to take a look at the contents of the credentials object at these various points and make sure there is a refresh token. If not, try revoking all the tokens and starting again, since it sounds like the first time you authorized the client you did so without requesting offline access.
If you are doing this yourself, best practice is to either refresh the access token if it has expired or is about to expire (since there may be some delay) before use, or (even better) attempt to make the call with an access token and, if it fails with an authentication error, get a new access token via the refresh token and try again.
I am trying to refresh the access token using the refresh token:
curl https://login.salesforce.com/services/oauth2/token -d "grant_type=refresh_token&client_id=3MVG9pHRjzOBdkd.WU9DLyfznP.sjOJRXXX_00nLDYSpM_0K7zAOsLrRKf6IWmCv6MxeTorXL7Zzaaea8IXXX&client_secret=3231123171523457&refresh_token=5Aep861VUUSqKxtr91VaZ7Zh54RmFqHE6zD4htOq6vY9edPgkgm9ZeFPwHIzQQvR__XypcEvWnXXX==&format=json"
But I keep getting the error "error_description":"expired access/refresh token"
Anyone have any idea?
I know this is old, but for people that may stumble on this.
I believe this issue is that you can only have 5 access grants per applications. After this it starts revoking refresh tokens from the oldest one. More info here:
Manage OAuth Access for Your Connected Apps
invalid_grant —expired access/refresh token | Issue #80
You have the correct syntax for using a refresh token. Make sure all of your parameters are URL encoded, since in your example your refresh token has = instead of %3D.
You can also delete the user's refresh token by going to that user's User Detail page inside of setup and revoking the "Remote Access" near the bottom. Then obtain a new refresh token by going through the oauth flow again and try it in the curl command.