Is it possible to verify to third parties, that a user has given authorization to an app?
As a fallback, the third party could send a challenge token to the app, which would then be tweeted by it, thus demonstrating it has authorization. But ideally it wouldn't have to pollute the twitter stream.
Maybe instead of tweeting, the challenge would be to follow, then DM a message? At least that's not public?
Related
At work we have never used 3rd party Auth solutions and I'm trying to inform myself of how they work for my personal projects. Getting the response is easy enough, but feel a bit lost on what to do after I get the response back. Am I supposed to send the auth token to the backend so it can be verified then trigger my app's login process for the given e-mail address/username? Logging them in essentially without a password?
There's two basic use cases for OAuth 2.0 which will determine what you do after the user is authorized. Your use case can also determine which OAuth 2.0 permission scopes you request the user to authorize your app for.
1. Single Sign-on
A simple use case for using a 3rd party OAuth solution is to leverage the 3rd party to perform authentication. Two reasons for this include:
Your users may wish the convenience of logging in with another provider (like Google, Facebook, Twitter, etc.), one where he or she may already have an active session.
You may not wish to implement your own login / authentication / password reset process.
Either way, a common way to implement this is to make an API request using the token to retrieve the user's email address after a successful authentication, which you then map to your own user database to establish an authenticated session for your service. Since you only need to retrieve the user's email address and minimal other information (e.g. name) in this use case, you can ask for a minimal set of scopes.
I do this in my oauth2more library where after receiving a token, I have a generic interface to load a user data which I convert to a SCIM user object. Because I've abstracted the code to retrieve user info in this manner, it's easy to support SSO across mulitple auth providers.
2. Using Service Features
A slightly different use case is that you want the user to authorize your app so you can make commands on behalf of the user via API. In this case, you will use the token to call more general APIs to accomplish your goals. A caveat is that you will need to make sure you ask for the proper permissions when asking the user to authorize your app.
As an example, one thing I've done is ask the user to sign in with Google so I can then make API calls to create and edit Google Sheets and Google Slides using APIs on their behalf.
This is more of a general question but I hope it is still valid for SO.
So far I have learned, that in general, a mobile app (such as official Pinterest app) use the Password credential flow to let their users login and access the API directly. (let's just assume they use OAuth for this)
So they collect username and password, send it to their server and get a token in return which is used for subsequent requests.
Now a user did not want to register and created an account using e.g. Facebook as the authorization server. So my question is:
How is this flow implemented?
My educated guess:
User chooses "Login with Facebook" in mobile app
Facebook Login Page opens with return_uri = mobile app
Mobile app receives auth token
Mobile app uses client credentials and says the API: Use this token for user X
Is this correct?
First of all, apps should not use the Password Credentials Grant. The specification is rather clear about it:
In the traditional client-server authentication model, the client
requests an access-restricted resource (protected resource) on the
server by authenticating with the server using the resource owner's
credentials. In order to provide third-party applications access to
restricted resources, the resource owner shares its credentials with
the third party. This creates several problems and limitations
The specification then goes on describing those problems.
And about the Resource Owner Password Credentials Grant:
The authorization server should take special care when enabling this grant type and only allow it when other flows are not viable.
The entire purpose of OAuth 2.0, I to not have to use something like the Password Credentials Grant, where the user hands over their password to the application.
About your second question: what happens when a user does not want to register and create an account with your app, but wants to use e.g. Facebook for authentication?
Remember that both the Implicit Grant, as well as the Authorization Code Grant, work by using a browser control to authenticate the user. In that browser session with the Authorization Server, you are free to authenticate your user in any which way you want. Certainly, you can use your own user/password database, but you could also use other mechanisms, such as WS-Federation. In your case, it sounds like the user want to authenticate using Facebook.
Authenticating using Facebook is then not done by your client app, but by your Authorization Server. It typically does that by using the Facebook Authorization Code Grant, followed by a call to read the user's profile to obtain their Facebook user id, name, and so on.
If you do not want to build such an Authorization server yourself, you can use an existing one. Several companies offer login-as-a-service solutions, including the one I work for.
UPDATE: You asked several follow up questions in a comment below. I'll answer them briefly here:
First of all, the fact that some companies that use OAuth to secure their services allow for a Password Credentials Grant, does not imply that you should. In fact, there are probably more examples of companies that don't offer this possibility, than companies that do.
There are real trust issues, and real security risks with sharing your password with a device app. To start with, the app on the device is easier to hack than a server. Furthermore, if you give the app your password, presumably that app also needs to store it somewhere for future use. As a user, I just have to hope that that storage is safe form possible malware running on my machine. For more issues, see the introduction in the OAuth 2.0 specification mentioned above.
Secondly, all good Authorization Servers differentiate between First Party Clients and Third Party Clients. A First Party Client such as yours is controlled by the same company that controls the Authorization Server, and for such an app the Authorization Server does not ask for user permission to share data, since it makes no sense to talk about sharing data with yourself. That is why the web sites of these companies don't ask you whether you allow to share the data they hold on your behalf with them. They already have it, and there is no "sharing" going on.
Of course, you might argue that you have never seen any of these companies talking about this distinction between First Party Clients and Third Party Clients. But the reason they don't should be obvious: when you deal with them, you are always a Third Party App. They don't need to tell you that they treat themselves differently.
The mechanism I would choose in your scenario depends on the nature of the client app, and the nature of the services it accesses. What are your requirements?
Anyway, if the device the application is running on has a secure storage facility, such as Windows Phone 8.1, I would probably consider using the Authorization Code Grant without client credentials. That way, the user never has to log in again. If we're talking about a web site or a SPA, I would consider the Implicit Grant (where the "remember me" feature, if any, is offered by the Authorization Server). Again, the specification gives advantages and disadvantages of each grant type for several scenario's.
I see that when connecting services to twitter/facebook, sometimes apps are storing the user access token in the server. What is the most common purpose of doing this? I've read several twitter/fb documents and just don't seem to get it. Twitter also has an xAuth which can basically provide you with the user 'access_token', so what is the purpose of doing this?
You don't want 3RD parties pretending to be users. You want signed transactions so that authenticity is validated.
What if some application just started posting shit on your wall? This has a pretty obvious purpose.
Your app has to provide the token when making API requests that have been approved by the user. That's what OAuth is made for.
Instead of the service storing your facebook/twitter username/password on the server (which the service shouldn't know) it stores the access_token. The access_token can be used to make requests to the API. This is the purpouse of Oauth. It will enable you to write services which uses an external api like facebook without the user ever telling you theire username/password
I have to integrate the web application I am developing, with an external web application in order to use their services.
Unfortunately this is my very first work and I am a bit confused.
They asked me to provide the verification URL with login token to help them identify which users come from my website.
Users from my app want to get information from 3party app database
To do that, the 3party app need to know who they are because, there are different roles in app. And each of them will have different privileges on the 3party app
Login to 3party app has to be in my app. They just want a verification URL with login token.
Is it possible to use token authentication through devise to do that?
Can I generate a token, store it in clients browser and than use that to get them authenticated in the external domain?
I hope this answer isn't too obvious. Sounds like you're just starting off on this and need some guidance.
From what I read, I get the following requirements:
You need to be able to be the authentication authority for another app
The 3rd party app wants to exchange and verify credentials via auth tokens
The 3rd party app wants the urls to the API calls to do this from you app
I'll cover this in a broad sense, and let you search out a specific solution. Basically you need a way to generate secure authentication tokens. Devise should do this, along with authlogic and several others. What you don't want to do is try to roll your own auth token generation. Definitely use the gems out there to do this for you.
Once you've got tokens being generated, here's an overview of the basic transaction, where an auth token is simply passed as a parameter into a controller action (https is your friend in this transaction, FYI).
3rd party app makes an API call with a token provided by your app
Your app checks the auth token for validity, and takes whatever action is requested, if the authentication succeeds
Your app responds with authentication success/failure code, and any other response data that the 3rd party app requested, if the authentication was successful
How the tokens are handed off to the 3rd party app, so it can use it to make API requests, is a matter of how you want your app to work. However, a common practice is to use a method is something which follows the following pattern:
When the 3rd party app needs to make an API request on a user's behalf, the 3rd party app redirects to your app where the user enters their credentials (if they haven't already). This way the 3rd party app never gets the user's username+password directly.
Assuming a successful authentication, your app then redirects back to your callback URL, passing in as a parameter the auth token generated by your app. That auth token is what is used in future API calls, until and unless the auth token expires (it's up to you when they expire, of course, since you're the authentication authority).
If at all possible, it would be great if you can actually use an OAuth provider or some other mechanism that already exists to act as a 3rd party authentication means that both your app, and the 3rd party app trusts. To go down that route, check out this Railscast: http://railscasts.com/episodes/235-omniauth-part-1
...but of course, since you already have an existing app, and especially in enterprise apps, it's less common to be able to integrate oauth providers into your application. But either way, whenever possible it's almost always preferable to offload the authentication mechanism to another party. This is mostly because you want security experts to be worrying about, and updating their authentication services, and to leave the app code to you.
On the other hand, even if you don't go with an OAuth provider as way of solving this, the railscast noted above will give you an idea and pattern to follow when building your own API/callback mechanism. What you'll wind up with is a series of API calls/actions. The routes (urls to these API calls) can, of course, be anything. But as an example, they might look something like this:
/api/auth/:id {:controller=>"api", :action=>"auth"}
...which takes as parameters, the a unique key identifying the 3rd party app, along with the 3rd party app's secret key (essentially a password), and a callback url for both success and failures, and responds with success/failure, and a valid auth token upon success.
/api/some/restful/resource/call # example API call for some RESTful resource you make available
... etc. ...
Like I said, even if you don't go with a 3rd party authentication provider, following the railscast I posted (as well as the follow up episodes) will give you an idea of the implementation pattern that other robust APIs out there use. Setting up a demo application to do facebook authentication would also be very instructive, and would probably only take you a couple of hours, just to get a handle on the workflow.
I have a webapp which does a lot of ajax requests with the php server and database server. I have also created an iPhone app and an Android app, which have been working as offline apps till now.
Now I want to create an API which will be used to sync data between web server and smartphone apps. Should I be using OAuth for this? What I have read about OAuth - it seems like it is used if I want to open my API to be used by third party apps. But here I just want to ensure secure transfer of data between API and my own apps.
Can somebody shed some light on this?
The main usage of OAuth is to make third-party apps authorized to access private resources of a user on a website without giving user credentials to the third-party app. For example, suppose that Twitter wants to get the list of contacts from your Yahoo account. The traditional way is to give your username and password to Twitter. But with OAuth, you give them a temporary token (called Access Token) which authorizes Twitter to access your contacts on Yahoo for a limited amount of time (until either this token expires or you, as the owner of private resource, explicitly revoke it).
That said, OAuth is not about securely transmitting data on the web. That's another story which is usually achieved using SSL. Even when you use OAuth, you have to use SSL alongside to make sure data is sent and received securely.
So in your case, you have to see what the API is used for. If it's public API which doesn't give any private data to the callers, there is no need to use OAuth. If the API is for accessing private resources of individual users however, You may consider using OAuth. If you opt to implement OAuth, you may allow other third-party apps to access your API in future without any concern.
Well a lot depends on how you are securing your API. Is your API open to public specially the post urls? If your data is not something which every user should see, then how are you checking the authentication of the user credentials?
Most the important thing is that we should avoid sharing the username and password over the wire to check for authentication all the time. This means, your API should not require username and password to validate if the user is valid. Which you can do by sending the username and password from mobile or device id or some other thing.
In such situation, the OAuth server comes to the rescue. Basically, on one URL a user will send his username and password to get his access token. Once that is acquired, we can use the access token to validate each request and take necessary actions.
You can refer the videos where I have implemented OAuth server in Laravel 5 using bshaffer which is one of the best OAuth library for any PHP framework to user. https://www.youtube.com/watch?v=0vGXbWdtjls