I am using Scribe (OAuth1.0) as a mechanism so that users can use their Twitter account to authenticate to my GWT/GAE application.
According https://dev.twitter.com/docs/auth/implementing-sign-twitter, there are 3 possible scenarios:
a/ User is Signed in and approved. In this case, Twitter should redirect the user transparantly back to my application url,
b/ user is Signed in but not authorize, or
c/ user is Not signed in
When Twitter comes back to my application (the callback), I use the verifier parameter to read the user data from twitter, which I use to determine the user in my application.
All of this works fine except for the following:
Scenario a/ is not working for me. Eventhough the user has already authorized my application to read his user data, Twitter seems not to remember this, and asks again to authorize access. (scenario b/).
There are two URLs twitter offers for applications requesting an OAuth token:
/oauth/authenticate and /oauth/authorize. When an application directs users to the authorize endpoint - Twitter will request the user to authorize the application EVERY time they log-in. The authenticate endpoint will request authorization once and then any subsequent log-ins to Twitter will seamlessly pass-through to the application callback. This is more traditionally known as "signing in with your Twitter account".
In Scribe, the default is authorize - to change this to authenticate you need 2 things:
Ensure the Allow this application to be used to Sign in with Twitter setting is checked in your Twitter application settings page.
In your application - when you specify the Scribe API class to use - instead of using org.scribe.builder.api.TwitterApi.class change this to org.scribe.builder.api.TwitterApi.Authenticate.class
Now your application will direct users to sign-in to the /oauth/authenticate endpoint and, if they have authorized your application at least once, they will just get passed through.
Edit:
Additional documentation - https://dev.twitter.com/docs/api/1.1#102
Related
I am about to embark on adding a 'post to Twitter' feature on a web application.
It appears 3-legged OAuth is the only option for this. The developer documentation states however that "The user will always be prompted to authorize access to your application, even if access was previously granted."
https://dev.twitter.com/oauth/3-legged
This doesn't seem like a very good experience for the user and confusingly this is not what happens on services like Hootsuite. Have they organised an agreement with Twitter so users don't have to keep authorising the app?
Use the Sign-in With Twitter flow, and store the access token that the user receives when they grant access to your app. Then there's no need to go down the oauth/authorize route every time.
I've implemented sign in with Twitter such that users can log in and I store user's credentials. However, on their tutorial page it says:
Signed in and approved: If the user is signed in on twitter.com and has already approved the calling application, they will be immediately authenticated and returned to the callback URL with a valid OAuth request token. The redirect to twitter.com is not obvious to the user.
In the diagram, my app never redirects transparently, it always asks users to grant access:
Is there something I have to do to make my app redirect transparently? My website is over https if that has anything to do with it.
Change the endpoint to http://twitter.com/oauth/authenticate instead of http://twitter.com/oauth/authorize
I'm building an app that requires users to authenticate with Salesforce. However, the problem I'm encountering occurs when Okta (SSO) steps in to authenticate the user automatically. The user is authenticated and redirected to the Salesforce home page, rather than the OAuth callback redirect as configured in the connected app (and passed as query param).
This is happening between steps 3 and 4 on this diagram:
Question: Is there a way I can prevent Okta from automatically authenticating a user on a page?
Just wanted to circle back and post my answer. It was simply the authorization server url. Instead of directing a user to a specific Salesforce instance (i.e., "na17.salesforce.com"), use the Salesforce auth server (i.e., "login.salesforce.com"). This keeps Okta from identifying the specific subdomain and trying to authenticate.
I'm using Rails to write an API for mobile application and OAuth seems like a standard way to handle user authorization.
If I understand Doorkeeper docs correctly it requires user to be signed in with the website before it grants access for the mobile app.
The issue in may case is that there really isn't any website (it may be in the future but for now it's just api). I would like the user creation/signing in etc be handled in the ios application.
This makes me wonder if OAuth is the correct solution here?
The OAuth "Resource Owner Password Credentials Grant," according to rfc6749 Section 4.3, will grant an authorization token and optionally a refresh token given user name and password. Thus the mobile app doesn't have to store user name and password to gain authorized access. It becomes like a long running session using token and refresh token. OAuthClientSetup an iOS example that runs against a doorkeeper api.
So there is the OAuth method for gaining authorization without having web site login authentication and access grant.
What is left is how to register new users from your mobile app. Agree that does not look to be covered by OAuth. OmniAuth will let you register a user authorized by a third party site. You allow the user to be the user they are on Twitter or FaceBook, StackOverflow or GitHub or wherever else. Maybe that would help.
I'm building an app with both a web client and a iPhone client.
On the web client I authenticate users through Facebook with Omniauth, the user can then post actions on the app to Facebook. That works good.
I'm having some problem implementing the Auth flow from the iPhone application.
I've set up Doorkeeper in the rails app as an OAuth provider. Although I'm not sure how the authentication flow should be implemented.
I've come up with this:
The user can log in to Facebook in the iPhone and get a token. The idea is then to send the token, along with the Facebook uid to the rails app, store it, and authenticate the user with Omniauth. Once the user is authenticated generate a token with Doorkeeper and send it back to the iPhone app.
If it's the first time the user authenticates against the rails app, a new user will be created.
The user can then do actions against a JSON-api and the rails app will take care of the Facebook integration since the Facebook token is stored on the user record.
The application will also span over several domains so I'll need to have multiple Doorkeeper applications registered to provide different callback uri's.
Does this seem like a viable solution?
Is it secure?
Is there alternative flows / approaches?
Thanks.
The solution I went with is summarized as followed:
Client starts oath flow w/ Facebook (using login button etc)
Client gets auth token and posts back to server
Server looks up user via FB API call w/ token
Server does lookup/create of user based on FB id
User is logged in if a user with FB id association lookup is successful
I have a diagram and more detail here: http://www.eggie5.com/57-ios-rails-oauth-flow