I'm new to OAuth, and it took me a while to find out that I had to put "Authorization: Bearer {{my access token here}}". So I was hoping to ask this question.
I open this link in a tab every time my add-on starts:
'https://www.dropbox.com/1/oauth2/authorize?client_id=' + authParam_client_id + '&response_type=' + authParam_response_type + '&redirect_uri=' + authParam_redirect_uri + '&force_reapprove=' + authParam_force_reapprove + '&disable_signup=' + authParam_disable_signup;
However is there an easier way, as once the user allowed my app for first time, then I shouldn't have to open tab for him to click that allow button right?
Oh aside:
Where is this auth bearer thing documented?
Thanks guys!
First, just for the sake of clarity, note that everything in your question is specifically about OAuth 2. There was also a previous specification called OAuth 1. The Dropbox Core API (v1) supports both OAuth 1 and OAuth 2, with OAuth 2 being preferred. Dropbox API v2 only supports OAuth 2.
As far as documentation is concerned, the actual documentation for OAuth 2 itself is the official spec, available here:
https://www.rfc-editor.org/rfc/rfc6749
For the Dropbox OAuth 2 endpoints in particular, the documentation is here:
https://www.dropbox.com/developers/core/docs#oa2-authorize
There's also a useful blog post here:
https://www.dropbox.com/developers/blog/45/using-oauth-20-with-the-core-api
In addition, there's a more general guide here:
https://www.dropbox.com/developers/reference/oauthguide
Once you have an access token for a user, you can store and re-use that access token. Dropbox OAuth 2 access tokens don't expire by default (though the user or app can manually revoke them), so your app can just re-use the existing access token for a user as necessary, without sending them through the app authorization flow each time.
The access token is just a string, so you can store it using whatever data persistence method is available to your app. Access tokens are very sensitive pieces of information though, so be sure to secure them with whatever means available and necessary for your app.
Related
I'm just looking at migrating an existing Login with Facebook flow over to Sign in with Apple with the hope of eliminating FB Login entirely from our iOS app.
The client side seems straight forward enough, however there's one topic I can't seem to see any documentation or discussion on Stack Overflow about - a Sign In with Apple equivalent for FB App Access Tokens.
Facebook Login supports different token types (https://developers.facebook.com/docs/facebook-login/access-tokens/) and currently our app back end supports 2 authentication flows.
From End App Users, they Login with Facebook, send the provided client User Access Token to the app backend which validates the token against Facebook and then issues an app specific JWT token to the app client that is used in further app API calls until expiry.
From backend server components. These request an App Access Token from Facebook e.g.
curl -X GET "https://graph.facebook.com/oauth/access_token
?client_id={your-app-id}
&client_secret={your-app-secret}
&grant_type=client_credentials"
The App Access Token is then send to the app backend which validates the token against Facebook and then issue an app specific JWT token that is used in further server to server API calls until expiry.
Replacing 1 above seems straightforward but what about 2? Is there a mechanism for achieving the same flow with Sign In with Apple?
It seems like the https://developer.apple.com/documentation/signinwithapplerestapi would be the API to use for validation but is there a way to generate an App Access Token equivalent for Sign In with Apple in the first place to validate using this REST API?
Thanks
I think it's possible
I'm not exactly sure how to really use it or validate it yet, but you get an access_token in the response from https://appleid.apple.com/auth/token when Generating and Validating Tokens
Getting an access_token from Apple
This example assumes you have an Authorization Grant Code, but the same is possible if you have a refresh_token, etc. instead.
Prepare a POST request to https://appleid.apple.com/auth/token
Fill out the following key-values as x-www-form-urlencoded:
client_id
client_secret
code
grant_type
redirect_uri
If successfull, this will return:
**access_token**
token_type
expires_in
id_token
I'm not sure if this is the type of access_token you're looking for, but I wanted to bring it to your attention.
It may be useless for now
After writing this, I came across this thread in the forums where Apple said:
Currently, the access token only indicates a successful refresh token validation. There are currently no endpoints where it can be used and it is reserved for future use. So, it can be ignored for now.
My app logic (Android, iOS and Web) is all written in my server.
Since things got complicated, I decided to build my server as a REST web service so querying it will contain logic in the header.
My login flow is pretty simple, and I somehow tried to copy from Facebook API:
The user login to Facebook.
The user receive a Facebook access token
The access token is sent to my server with some other identifiers
The server checks with Facebook that the access token is valid with Facebook and that the other identifiers match the ones on Facebook.
The server returns an access token to the user, which he should use in each query until it expires.
The problem is that I didn't add any other restrictions like endpoints limitations (scopes) and stuff like this, so an access token generated by my server grant you access to each part of my api.
I think that inventing the wheel here will be foolish, so I'm looking for a framework or a generic solution that will allow me to add logic to the access tokens in a simple way.
I read about OAuth, but my concern that its more about user sharing with other users, but I only want to use it is login flow and scope protector.
Is it possible with OAuth ? Are there alternative to OAuth ?
That's possible with OAuth 2.0 and in fact one of the objectives: you may issue and use access tokens that have particular "scopes" (an OAuth 2.0 concept) associated to them that could relate to permissions that the client has (e.g. read/write, API A, API B).
But you need to issue your own access tokens from your own Authorization Server. You could allow users to login to that Authorization Server with their Facebook account.
Using app access token had previously been asked in this question (How to use Facebook appAccessToken with Spring Social) and Craig Walls gave a good explanation why the spring-social API should be user-based for most cases.
I have a scenario, however where I would like our server-side application to make a couple of queries that should not require user-specific permissions. I picked a random public page for examples below
I would like to:
View details about a public page by alias/id
https://graph.facebook.com/v2.0/121727254549188
https://graph.facebook.com/v2.0/peterstevensmotorcycles
View posts for a public page by alias/id
https://graph.facebook.com/v2.0/121727254549188/posts
https://graph.facebook.com/v2.0/peterstevensmotorcycles/posts
Search for pages
https://graph.facebook.com/v2.0/search?q=Peter%20Stevens%20Motorcycles&type=page
When I test these in the Graph API explorer (https://developers.facebook.com/tools/explorer) using an App Access Token they work fine. App Access Token is obtained by hitting https://graph.facebook.com/v2.0/oauth/access_token?client_id={app-id}&client_secret={app-secret}&grant_type=client_credentials and replacing client_id and client_secret with my Facebook client credentials.
Our application would like to have the ability to make these for any given name so we can make queries about a company's presence.
We will have similar requirements for Twitter, LinkedIn and others so I just wanted to check if there are any means to do this in the current API or whether it will not suit our requirements.
You do not need to fetch an app access token - you can actually use the app id and secret separated by "|" as the access token. - You can see it at the bottom of the app access token section in the documentation: https://developers.facebook.com/docs/facebook-login/access-tokens#apptokens
Spring Social's Facebook API binding does not (yet) support v2.0, but that's something I'm working on right now...so hopefully soon. Once that's complete, there'll certainly be some operations that work only with user access tokens and some that only work with app access tokens, and some that will work with either (FWIW, Twitter's API has a similar set of circumstances).
Keep an eye on the project in GitHub or follow #SpringSocial on Twitter to know when the v2.0 stuff is available. (I'd appreciate any help I can get in testing it.)
Although it makes no sense at all to obtain your FacebookTemplate via the connection framework for app token requests (connections are, by nature, a user-oriented concept), you can always construct a FacebookTemplate wherever you need it, giving it an app access token obtained via OAuth2Template's authenticateClient(). You can certainly do that now with the v1.0 API binding, but I'm uncertain what ops an app token would work with.
FWIW, as I'm working on the v2.0 API binding, I'm starting to sense an opportunity for FacebookTemplate to carry two tokens: A user token and an app token. This way you can perform app-centric requests even from a FacebookTemplate obtained from the connection framework. Then the only time you'd ever want to construct a FacebookTemplate manually is if there are some operations for which either kind of token will work, but the results would be different depending on what type of token is used.
I'm using the URL below to get the auth token:
https://www.facebook.com/dialog/oauth?client_id=CLIENT_ID&redirect_uri=RETURN_URL&scope=manage_pages,publish_stream
This page will redirect to another URL with the code token in query string. I'm using this code token to get the Page access token automatically and publish to the Page 'offline'.
In recent days, it seems that Facebook has changed the expiration time of this token code.
I am able to use this token once. The time expiration is very short. Anyone know if there really was a change in facebook? Is there any other alternative to work with this?
This was part of the December 5th changes on the Roadmap: the code can only be exchanged for an access_token once and must be exchanged within 10 minutes of generation.
New security restrictions for OAuth authorization codes We will only
allow authorization codes to be exchanged for access tokens once and
will require that they be exchanged for an access token within 10
minutes of their creation. This is in line with the OAuth 2.0 Spec
which from the start has stated that "authorization codes MUST be
short lived and single use". For more information, check out our
Authentication documentation.
If you're unsure how to log users in correctly because you were relying on the old, incorrect behaviour, ensure you're using the newest SDKs and read the Login documentation in detail, specifically the Server Side Login documentation which shows how to exchange the code for a token
Once you have the token, save it using whatever session storage mechanism your app uses (PHP SDK will store it in a PHP session for you) and use the access token on subsequent calls instead of trying to obtain a new access_token from the code
On my app the user can sign to Facebook and the app then has the user's access token (say it's 'abc'), I want to use this token to create a user on my own server.
Is it safe to send this access token to my server (using SSL), then get the user's username and ID using https://graph.facebook.com/me?access_token=abc on my server and check that the application the token belongs to is mine with https://graph.facebook.com/app?access_token=abc. If it is my application I then store the user in my user's database and/or log them in.
Can this system be fooled? Can you think of a way someone could log in as someone else?
You should check out all of the Authentication documentation and the Oauth spec to see the different auth flows available
Broadly speaking, you can create a user on your server based on the access token, and be reasonably certain that when you get an access token from Facebook for the same user ID that it's the same person.
If you require very high security for the app you can take steps to ensure the user's access token wasn't produced via malware or the Facebook user being tricked, there's an example showing protection against CSRF in the Server Side Authentication documentation, and there's also a reauthentication flow you can use
I assume that you are using facebook sdk for this, if so the facebook sdk takes care of the security for you and you don't have to worry about a thing.Supposing that you are accessing the api without the sdk then there are two things that must be noted:
1) Auth token expires frequently(facebook has taken great pains to ensure that the user is protected)
2)Making a request with just auth token is not enough there are some other parameters that are needed that can't be faked especially if you are doing this server side since an extra layer is added that fb calls server flow authentication
3)On top of that there are a lot of permissions that are in place that the user has to give in order for an application to access some data.The link below provides a nice article on authentication you can take a look
https://developers.facebook.com/docs/authentication/
So long story short it is safe.