I will explain the scenarios here
1) When user click on link facebook button facebook permission dialog is bypassed and returns back directly on redirect uri(http://localhost:3000/ in my case) with code and state.
2) I am successfully able to exchange the code return above with access token.
3) I used facebooks access token debugger to analyze the token above and shows be proper scopes i need.
4) After this i fetch ad_accounts id, page token and page ids using this token.
5) when i use this token to create campaign for ads i get the following error.
FacebookAds::ClientError (Invalid parameter: Terms of Service Not Accepted (fbtrace_id: Ch/RdwGB+D3))
I use ruby facebook-business-sdk.
My app is in development mode and not live yet.
I can see both facebook login and marketing api green live in my app dashboard.
It makes sense to me that i am getting "Terms not accepted error" as user is never prompted to permissions dialog to permit my app for token.
I also observed that if add scope params to facebook login uri, the user is prompted to permission dialog.
I must be missing some configuration here, i have not yet submitted my app for review.
Any help/clue is appreciated.
Related
I'm currently testing SWIA implementations, and found some interesting behavior related to scope in the authorization flow.
Situation that I'm facing right now is:
User signs in with his/her Apple Id through the mobile app's or website's SWIA feature for the vert first time without email scope.
User will be granted JWT without email claim as expected.
Later, we changed to add email scope for the authorization process.
User (from #1) signs in again, and goes through SWIA with email scope
User will be granted JWT without email claim
Unless otherwise user manually de-authorize the app from their Apple ID portal (or in the mobile app), updated scope will not be reflected
It also happens in the opposite way (i.e. having email scope for the very first request, and then later remove email scope. This will still grant JWT with email claim)
Is this something expected from Apple's OIDC server? or am I doing something wrong? I've tested it with both native iOS SWIA and on the web client as well, and both produce the same result.
Not quite sure if this is as per OIDC specification.
Any insight or help would be greatly appreciated.
I know its a late reply, Sign in with Apple does not provide incremental changes to the user scopes. If some user authorized with initial scope won't get until he revoke our application as described here https://support.apple.com/en-us/HT210426.That mean the newly added scope, only affects newly authorized users, and would include the email claim in their identity token (and in the initial user body of the authorization response).
Additionally the above steps don't show the option to revoke the app until at least one of the app login happens and the app should be in production not sandbox or testing.
apps not showing as there is no app requested for email/name
it will appear if login success from production app
Slack provides the ability to make a Direct Install to install your application.
When you save your Direct Install URL, Slack will attempt to send a simple HTTP GET request to your declared URL. If it doesn't detect a HTTP 302 redirect pointing back to a fully qualified slack.com/oauth/authorize URL (see below), you'll receive an error letting you know.
...
First Slack sends the user to your Direct Install URL:
GET /slack/direct_install HTTP/1.1
Host: example.com
Then your server kindly redirects back to Slack's OAuth 2.0 authorization page:
HTTP/1.1 302 Found
Location: https://slack.com/oauth/authorize?client_id=12345.67890&scope=channels%3Ahistory%20users%3Aread&state=abcdefg
Resulting in the user jumping right into authorization. One point of friction removed.
You may continue to generate your own time or context sensitive state parameters and specific, pre-registered redirect_uri values as needed.
How does this integrate with my own apps user authentication? As I read it, the Direct Install URL must always 302 redirect to the Slack OAuth page. If the user isn't logged in to my application when they click the "Install" button, what am I meant to do?
My best guess is that I should:
Always redirect to the Slack OAuth URL and generate a state parameter to keep track of the request.
When the user finishes their authentication, they are redirected back with the code and state parameters.
If they aren't logged in, ask them to log in, and retain the OAuth code and state parameters. Once the user logs in, continue with the OAuth authentication process.
Is that right? Is there a way to force the user to be signed in to my app before trying to install the Slack app?
On a security note, for this to work with session cookies, I think they would need to be set to SameSite=lax, not =strict. The cookie wouldn't be passed from a cross domain request when they are set to strict.
I think you have a couple of options:
1) Don't use it.
The "Direct install" feature is a shortcut to the standard "Slack Button" installation process. Since in your case the user needs to first log into your app anyways, I think it would be more user friendly to also provide the Slack button in the same context on your webpage.
2) Return an error
If you detect that the user is not logged into your app, you could just return an error to Slack, e.g. http code 500. Slack should then also return an error to the user (not sure how it looks though). If you combine that with a clear message on your Slack App install page about the requirement to first login to your app that could work. This would be the easiest to implement, but also the least user friendly approach.
3) Request login to app after Slack login
After you completed the Oauth process and recognize that the user is not logged into your app you could request the user to login to complete the installation process. The disadvantage here is that your app would already be installed and could be left in an unusable state if the user failed to login at this point.
4) Halt Oauth process for user login
As you suggested you could halt the Oauth process after receiving the authorization code and request a user login to your app. Then continue the Oauth process after a successful user login. This can work if you need to take into account that the authorization code will expire after 10 mins. I do not see any way of forcing the user to login before he clicks on the direct install button.
I am trying to determine if page access tokens used with the messenger api are permanent. Seeing this code in one of their examples, which indicates to me that they are using the token as a constant value :
access_token: PAGE_ACCESS_TOKEN
I get the Page Access Token shown on my facebook app dashboard in this way:
I log into facebook, go to developer.facebook.com, select my messenger app, then on the dashboard go to Products > Messenger > Settings and can select my page and then get a token.
Can I put that value in a properties file and then use it indefinitely with my application when getting/sending messages to and from the page?
I am getting a bit confused regarding the documentation around other tokens, like user tokens and login tokens vs. page tokens.
Editing to add that I am using the page access token in order to make a POST request to this url : https://graph.facebook.com/v2.6/me/messages in order to reply to a message sent to my page by a user.
I believe I have solved this and wanted to post in case anyone else had the same confusion.
I assumed I needed to make a GET request to a facebook url in my code to get a new token before each Request to GET or POST to the messenger API. Using the information in the links above, I learned how to get an extended token here:
https://developers.facebook.com/tools/explorer/<my app id here>?method=GET&path=me%2Faccounts&version=v2.10
I then can use that ID indefinitely as it is supposed to not expire. I am going to assume it is OK to put this id into my properties file, if anyone has opinions on a better place to store this token value I would be interested.
Extended Page Tokens are valid forever.
You need to use a User Token, extend the User Token and then get an Extended Page Token with the Extended User Token.
More information:
https://developers.facebook.com/docs/facebook-login/access-tokens/
http://www.devils-heaven.com/facebook-access-tokens/
I am learning to use dropbox APIs and got confused when came up with the token flow.
As guide indicates, the flow should be like this:
the app redirect the user to a Dropbox webpage, i.e. .../oauth2/authorize
user logs in and approves the app
redirect back to the app. At this point, the app gets an access token.
However, when i requested the URL:
.../oauth2/authorize?client_id=xxx&response_type=token&redirect_uri=xxx
I was directly redirect to the destination with
REDIRECT_URI = "#access_token=xxx&token_type=bearer&uid=xxx"
And the "approve step" was skipped, i.e I got an access token without being allowed.
Is it a bug or my fault?
Any help would be appreciated :]
In certain cases, when the user has already approved the app to access their account previously, they will be automatically redirected through the app authorization flow.
If you want, your app can prevent this behavior from happening by using the force_reapprove parameter, documented for the /oauth2/authorize page here:
https://www.dropbox.com/developers/core/docs#oa2-authorize
I'm currently implementing an Oauth consumer service which is going to use Soundcloud as an Oauth service provider as well. But I'm having the following issue with it: Taking Facebook or Twitter example, you go there, you sign in, you fill up the permission form, and you are redirected back to your app. If you go there a second time, and given you are already sign in, you basically skip all steps and are redirected back instantly. That means, Facebook recognized that you already gave permission to that 3rd party service, so it doesn't ask your permission constantly.
And that's what's happening when I use Soundcloud. Basically everytime I redirected the user to the Soundcloud Oauth connect endpoint, the permission form always shows up, even though I already gave permission to that 3rd party service previously. I'm forced to press "connect" every single time, which is a drag from the user perspective (how many times can you give permission to the same entity). My question is: is there a parameter I can use to make soundcloud recognize/validate the previous permission from the user account to that specific 3rd party service? Or is this Soundcloud Oauth design implementation and we have to live with it?
Edit:
Maybe this wasn't clear, but each time I press "connect" in soundcloud, a new access token is being generated and delivered. Since my app uses this access token to identify its users, it doesn't work very well for me that the access token is getting updated everytime I want to log in, making me effectively "sign up" everytime. To sum it up, I want to get the previously attributed token to my account, so I can look up in my database, identify it and log him in.
I'm also looking for a solution which doesn't involve storing state in the client that might get cleaned up.
What you can do is store the user's oauth token in local storage and reuse it in future sessions. That's what happens on soundcloud.com.
A longer explanation:
When you use the Connect flow, the user is authenticated by SoundCloud (either by using username/password, Facebook Connect, or an already-existing session on soundcloud.com), and then when it is successful, your app is given an oauth token for that user. This is passed to the callback page which is registered for your app.
That token is the only piece of information needed to have the user be "logged in". Unless the token expires (by time, or by the user manually revoking it), then you can reuse that in future sessions.
I think I'm a bit confused about your application's design: where and how is the oauth token being used? I think that instead of using the token as an identifier, perhaps the user's permalink might be better? If you have the oauth token, you can find out the permalink by querying api.soundcloud.com/me.