I was hoping that someone could provide some context.
My organization is building a native external app. Our goal is to avoid being directed to the authorization server in any way (customer's requirement, not ours). I understand the benefits of the true redirect flow SSO, etc.
Using redirect flows I was able to use the acr_values attributes to redirect out to the third party provider to obtain a code; but I am still directed back to our identity server for the user to grant permissions to the various requested scopes.
Is there any way around this? We are using Resource Owner grants for our native login; and this works great. Likewise the redirect to the third party login is acceptable as well.
The customer doesn't want a user to have to grant permissions to scopes/roles for an app that will remain 100% proprietary.
Any thoughts would be appreciated!
I think this is a product of my limited knowledge of redirect flows. I was missing the RequireConsent property .... I set this to false and was able to proceed.
Related
I'm trying to get my head around OAuth from the context of having an API that I want to secure and a javascript based single page app made in Vue.js that will consume this API. I've been told that OAuth is the industry standard for this type of thing.
I want to let other clients like a mobile app also use the same API.
From what I can gather the right flow is Authorization Code Flow with Proof Key for Code Exchange (PKCE) https://oauth.net/2/pkce/
The bit I am confused over is how I seem to need to get users to approve access. For example you don't have Twitter saying "Would you like Twitter to use Twitter". If I was in the position of people using the account to create another account I wouldn't have any confusion but when the client is your own website what is supposed to happen?
I can sort of imagine that I could automatically approve the website or just bypass the part where the user approves but then I feel like I'm going off script. Then I think to myself, have I completely got the wrong end of the stick- is OAuth not designed for this?
If anyone can see where my ignorance is I'd be more than happy to be corrected!
Thanks!
OAuth and OpenID Connect enable you to authenticate users in many ways, for web and mobile clients. Each app implements a code flow and redirects to an authorization server (AS).
Each client is configured with an entry in the AS, and consent can be disabled when required. It is typically only enabled when personal assets are involved. Eg to grant a security code scanning service access to my GitHub repositories.
From asking around a bit and reading a bunch more found searching for "first party" providers: it is okay to just have the main website bypass the bit where they approve access and just send over the token.
I have a SPA which is going to consume an API we build.
We are in the process of adding OAuth of this API, the use cases we have are:
3rd parties will be able to use this API but will need to authenticate (I believe this will be some sort of authorization_code grant type)
Our SAP will also use this API (here is where we are a little bit lost)
For what we investigated it seems that authorization_code w/PKCE is the way to go for front end applications. But it seems that includes some redirects on the flow etc.
But really what we want is that our user lands in our SAP and and as soon as that happens the front end application authenticates itself (without any context of the user) as the SPA without user interaction.
This starts to sound similar to a client_credentials grant but that seems to be used only for server to server authentication.
Is that possible?
If that's possible how do I achieve it without exposing the credentials I give to my SAP (I assume the SAP will need to be the consumer of the API and need an account or something like that)
Please correct me If I'm wrong or completely misunderstood something. Still trying understand OAuth well.
Thanks!
All OAutt Authorization code flow examples I've seen sends the user to a specific login page provided by the IDP Server (Identity Provider Server).
https://auth0.com/docs/flows/authorization-code-flow-with-proof-key-for-code-exchange-pkce
I'm wondering can the login page be on the client itself, as in through an APP or SPA? Or is this something unsecure which I am not aware off. Thank
Usually it is standard to redirect as you say, but security also depends on the credential being used:
If a user is signing in via their Google password then your app should definitely never see the credentials and you should always redirect
If the user is signed in via a password stored at Company X, to only access data stored at Company X, and the password is not used for any other purposes, then it is less bad, since the company owns all of the assets involved
People who avoid redirecting usually end up using a deprecated flow such as Resource Owner Password Grant. I would avoid that, since it will not fare well in security reviews and restricts your future authentication options.
To be on the safe side I would recommend sticking to the redirect model, and using a login method provided by the Identity Management System vendor.
FUTURE DIRECTION
Interestingly, there is an emerging trend from some vendors to remain within the app when that makes sense. See the Hypermedia Authentication API, which may become a standard. A key characteristic of this is that the Authorization Server continues to govern security and tell the app what to do.
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.
We want to use Google Doc API to generate Document (In our own business account) when our end users do some actions on our site.
The problem is that we've tried to implement the OAuth 2.0 protocol, as suggested in the v3.0 protocol documentation. The apiClient::authentication method do a redirection. This is a major problem because our users doesn't know the access to our own business account.... and we don't want to give them access anyway ;)
(In other word, we're not creating an application that allow our users to edit their own data, but to interact with our data, like a database.)
I've read that the point of OAuth 2.0 was to avoid that we manage the credential of our users. I'm personally O.K. with the concept, but in our case, we don't want to get authenticated in the google account of our users ...
So, what would be the best approach to get a valid authentication without any interaction from the end user ?
What you describe is not how 3-legged OAuth was designed to be used.
3-legged OAuth is all about delegated authentication where a user (who knows his password) can grant limited and revokable resource access to application. That application never sees the user's password. There is a bunch of work involved to safely allow the application to impersonate the user.
What you probably want is to use the (2-legged) OAuth flow, where the consumer_id/consumer_secret credentials are embedded in your application. Here your application is not impersonating your end user and there would be no browser redirection involved.
Here's some further info on using 2-legged OAuth in Google Apps:
http://googleappsdeveloper.blogspot.com/2011/07/using-2-legged-oauth-with-google-tasks.html
And this is a good description of 3- vs 2- legged OAuth:
http://cakebaker.42dh.com/2011/01/10/2-legged-vs-3-legged-oauth/
You will need to use a SERVICE ACCOUNT. Basically you are hard coding access to this account into your server application. Then you use sharing to give access to the to account for the content you want. For example you can share a Google Doc or an Analytics profile with the SERVICE ACCOUNT.
Here is a complete example implementation of setting up a service account, logging and and then using it.
Updated 2018-12-12: https://gist.github.com/fulldecent/6728257
Why not get one OAuth authorization for your business account and have all users use that account. Since it sounds like you want everyone accessing the data for one account, the details can be hid from the end user.
The access token would be shared by all users and they would all hit the same account back end without any authorization for each user's own account.