I'm trying to figure out if I'm using the correct API calls to revoke my apps access to a users Twitter account (so when a user attempts to log in with Twitter again they have to grant my app access instead of not asking to log in)
On my app locally I have a server running where a user has the capability to grant my app access to their Twitter. I am successful at obtaining an access token using
https://api.twitter.com/oauth/request_token
but when it comes to revoking that same access token I've attempted to use
https://api.twitter.com/oauth2/invalidate_token
described here: https://developer.twitter.com/en/docs/basics/authentication/api-reference/invalidate_token
but it seems to use oauth1 to obtain the access_token and oauth2 to invalidate it which seems odd. I'm able to POST but the error I receive is 403 "Unable to verify your credentials"
In the description of invalidate_token call, it mentions invalidating an "OAuth 2 Bearer Token" but obtaining the token I obtained an "OAuth Request Token".
Can one authenticate with OAuth2 to invalidate a token obtained with OAuth1? Or am I missing something?
The server is running PHP and calls are with curl.
You cannot programmatically revoke OAuth1 tokens using the Twitter API, unless you are using Bearer Tokens. In your case, you are not using Bearer tokens, but standard OAuth1 request and access tokens.
Rather than revoking access, you can direct users to the GET oauth/authorize endpoint which requires the user to re-approve the application:
https://developer.twitter.com/en/docs/basics/authentication/api-reference/authorize
However, please think carefully about why you are doing this -- typically, a user grants your application permissions once and then revokes it themselves through their Twitter settings, as described here:
https://help.twitter.com/en/managing-your-account/connect-or-revoke-access-to-third-party-apps
Related
I am trying to get an access token using my dropbox username and password.
I don't want to go and generate it from there site, as mentioned in there help documents.
No, Dropbox API apps should use the OAuth app authorization flow to get an access token for the user, so that the app doesn't have to directly handle the user's credentials. You can find more information on this process here:
https://www.dropbox.com/developers/reference/oauthguide
The method of generating it on the App Console that you mentioned only works for the owner of the app, but the OAuth app authorization flow can be used for any account.
Note that while this does require manual user intervention, it generally only needs to be done once per user. Once the app has an access token for a user, it can store and re-use the token for future API calls without further manual user intervention.
Dropbox API access tokens don't expire by themselves, though they can be manually revoked by the user.
I'm trying to implement a "Sign in with ..." authentication system.
I've read several posts and articles on oauth2. Everyone that I've read stops the discussion or tutorial at getting the access token and possibly logging in the user for that session.
I understand that and can implement that part. Here's what I don't get:
When the user leaves the site and doesn't come back for a week, but they're still logged into the client, how do I log them back into my app? I know you save the access token to the DB, but how do you use that to log them back in?
If they're logged out of the client, how do you redirect them to the sign in page of the client. It seems that every time I try to log back in I'm asked to allow or deny the app again. I know that isn't standard, so how do I fix that? What do I send the client so that it knows that the user has already authorized the app?
I don't need a code sample unless someone knows of an article, what I would really like is just a high level overview of what to do with the access token after I have received and saved it.
Thanks!
EDIT:
I understand that OAuth2 isn't an authorization system in itself, but everyone and their dog has a "Login with..." option. And in order to do this it's necessary to use OAuth2 (or some form of API identifier). That's what I'm trying to do.
Does the following sound like the correct flow:
Get temporary code from auth server
Trade that for access token
Get user data from auth server and do whatever you want with it (probably save to a DB).
Log the user in, saving the refresh token as well.
Set an identifier in a cookie for the user (the access token)
When user comes back, identify them via the cookie token.
Try to make a call to the api and see if the access token is still valid.
If access token is still valid, great!
If access token isn't valid, then get a new one via the refresh token.
Is that the basic gist of using OAuth2 to help authenticate a user?
First of all, OAuth2 is not an authentication protocol. The issued access token does not sign you in, but allows you to call a web service (API).
OpenID Connect is an authentication protocol built on top of OAuth2. It allows you to get back an id_token from the authorization server that identifies the user. If you safe the token (or the info in it) in for example a cookie, you can establish a authenticated session for the user.
You also do not store access tokens in a database. Access tokens are short-lived and storing them on the server side serves no purpose.
You do store the refresh token in a database. When the client (app requesting the token) is confidential (can keep a secret), a refresh token may be issued. The client can use this refresh token to request a new access token for the API when the old token expires. This is what will surely happen when the user did not visit the app for a week.
This is what I do when using OAuth 2 tokens:
1.) You should store the access token in the local storage of your client. So once you stored it you can use it for every request you make like adding it to the Authorization Header "Bearer " + accessToken;
Don't forget to clear the local storage of your client when they logout.
2.) Basically if you send a request to the API and it returns "HTTP Error 401 Unauthorized" (Status 401) then you know that you should immediately re-direct the user to the login page because he/she is not authorized.
Well, if you are using role-based authorization then there's a possibility that the user is logged-in but is not authorized. This scenario should be handled by you. Only display actions on the UI corresponding to the authorization level of the user.
Hope this helps.
I don't quite understand the api flow for twitter on a per-user basis for API transactions.
Here's my understanding of the user transaction flow:
1./ User signs into our web application.
2./ User authenticates with twitter and then the API sends the user back to a callback destination with a provided oauth_token and oauth_token_secret.
3./ We store the oauth information into a database.
4./ Now we have there access tokens and can send tweets on their behalf without needing them to log into the application again.
HOWEVER, this is not working correctly. When I try to supply the oauth token information, i'm getting invalid or expired token. OK so instead i supply the oauth token provided to me with the user oauth tokens given by the owner of the app and it works.
I think I'm mishandling the authentication process.
I'm reading here at the authentication docs.
Can anyone help me understand how i get my app to handle status updates on a per user level?
Thanks.
Ok. However I read for twitter there is no expiration
This is the actual transaction flow your application will take in order to use Twitter:
Register your application to Twitter to obtain an OAuth consumer_key and consumer_secret. This is for Twitter to identify the application that your user will authorize to access it's account.
When the user wishes to Tweet or access their Twitter resources through your app, The OAuth handshake process will redirect to Twitter, with the application's consumer_key so that the user will authenticate on Twitter directly. Once user authentication is successful, Twitter will provide your application with an access_token.
That's essentially what happens, except that Twitter uses OAuth 1 protocol so the handshake is more lengthier.
Access Tokens do expire for security reasons. It's like when you login to a system, the session is active for a period. When they do expire, you will have to request for an access token again.
I don't know if that explains your question.
I'm new to oAUth2 and I'm trying to get a few things straight.
I understand the basic principles involved with oAuth2 but I am not sure how to implement it in my situation.
I am writing an app that acts on behalf of the user to automate a manual process and perform some tasks(update/request status...etc). The API we are connecting to uses oAuth2 to grant our application permission. We plan on having the user grant our application permission when they create a new account with us.
I understand that the user will request an authentication code that is provided to our application. Then our application will use the authentication code to generate an access token.
We would like to do this only once. Then act as the user to send and receive notifications without having to have the user to log into the service with their credentials.
I am not sure how to implement this without having to store the user credentials to get an auth code since the auth code and auth tokens expire. I'm guessing that this is a common scenario.
What would I need to do to get what I want accomplished?
You can get a new AccessToken using a RefreshToken, if this is provided by the Authorization Server.
If it's not provided I would contact the Api provider, you should never store a users credentials. In fact if the OAuth protocol is well implemented as a client you should never be able to even get the client credentials. When the user has to login you should redirect the user to the Authorization Server, there the user should login and then the authorization token should be redirected to your application by the Authorization Server.
See also this explanation on Refresh Tokens from the OAuth 2.0 spec:
Refresh tokens are credentials used to obtain access tokens. Refresh
tokens are issued to the client by the authorization server and are
used to obtain a new access token when the current access token
becomes invalid or expires, or to obtain additional access tokens
with identical or narrower scope (access tokens may have a shorter
lifetime and fewer permissions than authorized by the resource
owner). Issuing a refresh token is optional at the discretion of the
authorization server. If the authorization server issues a refresh
token, it is included when issuing an access token
Note
If you request a new AccessToken using your RefreshToken and the response includes a new RefreshToken you should overwrite your currently saved RefreshToken. With other words, you should always use the latest RefresthToken you received.
I'm using omniauth-salesforce gem to access salesforce data in my rails app. I'm able to login to salesforce using oauth and get the authorization code back in my app in no time. But how do I get the access token for further REST calls.
OAuth2 tokens expire after a certain duration. You can cache these bearer tokens per user per session (perhaps as a cookie?).
You will also want to capture the refresh token. The access token could expire while the user is still interacting with you. If so, you can use the refresh token to get a new access token without user intervention.
More details on OAuth2 can be find in the RFC 6749 definition.