Within our application there's a possibility of using authentication with OAuth 2.0 several times. First authentication will show us an authentication dialog box, when we want to do it one more time (second authentication) we are redirected without authentication dialog box to redirect_uri.
How is it possible to always see the authentication dialog box?
That will generally require support from the identity provider and as far as I'm aware LinkedIn does not support this, neither in a standard way or provider-specific way.
In accordance to the standards this would be accomplished by using the OpenID Connect prompt parameter when performing an authentication request. You would pass the login value and the provider, if compliant to the specification, would need to:
login
The Authorization Server SHOULD prompt the End-User for reauthentication. If it cannot reauthenticate the End-User, it MUST return an error, typically login_required.
However, I don't know how widespread support for this is. In LinkedIn, I think support is nil. Google also does not list the login option as a supported value in their documentation, however, they support select_account which may solve some scenarios. Another example, Auth0 does support the reauthentication through prompt=consent although it's not documented anywhere, so might change.
Related
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.
Is opening a browser to display a login page, which was generated from the site performing the authentication, built into the OAuth2 specification?
My requirements and constraints are going to prevent me from having a browser on the device. However, a request to authenticate the user against Azure Active Directory has been made. They are really looking for the desktop application to have fields in its own GUI for the username and password, and the ability to check if that's a registered user or not.
Is opening a browser to display a login page, which was generated from the site performing the authentication, built into the OAuth2 specification?
It is related to used OAuth2 flow specification, not to OAuth2 specification.
My requirements and constraints are going to prevent me from having a browser on the device.
That means you can't follow RFC8252 (where that browser is required).
So your only option is Resource Owner Flow/Direct Access Grant. But it isn't "secure", because app will have access to user credentials. Other cons: single sign-on won't be working, some IDPs may have also problem with multi factor authentication for this flow and security enterprise departments also don't like this flow at all usually.
We currently have a typical forms authentication setup in our organisation; with a login page located at something like account/login. We want to retain this but also want to start securing some of our APIs with OAUTH2 ; essentially we are the provider.
From reading a fair bit about the subject Microsoft's OWIN OAUTH implementation moving forward isn't supported (e.g. vNext) and doesnt support all the flows with OAUTH2. Thinktecture's identityserver3 seems to be the "standard" and most complete solution there is currently.
I cant seem to find an example of using identityserver3 with an existing app that requires forms authentication.
We would be looking at using it in two different ways; one using the implicit flow using javascript where we allow a third party site to call our API once the user has logged in to us (using the forms auth) and the user has allowed the client to access specific scopes.
The other use case, I think , would use the authorisation code flow ; the client would be requesting this so it can auto login (much like a login with Facebook - but login with X company) or be already logged in if logged in our site.
Any help with these scenarios would be most appreciated.
I think it will not be possible to switch your app to OAuth without changing your existing login.
I would suggest you use Identity server with custom user store(https://identityserver.github.io/Documentation/docsv2/advanced/userService.html) to use your current user database. That way your existing login accounts will be used by the identity server.
You can then secure your APIs with OAuth using the Identity server. You might need to change the way your current app call the APIs too. This means users of the current app will be redirected to identity server's login page. You can brand your login pages using custom views to make it appear similar to the curent login page (https://identityserver.github.io/Documentation/docsv2/advanced/customizingViews.html)
Currently in the process of moving from OAuth1 to OAuth2 in a desktop application for a web service (Imgur), I've been baffled by the OAuth2 specs. Apparently it breaks all the security OAuth1 provided, according to this doc http://aaronparecki.com/articles/2012/07/29/1/oauth2-simplified and by looking at different services docs regarding OAuth2.
With OAuth1 you could use a URL to the service where the user would grant access and a PIN was displayed to copy/paste in your app, which was really nice security in the sense that the user never grants their login/password to the app, and can revoke the given access to it at any time through the service's website.
Now with OAuth2 they left this scenario out, forcing the app to request the user's login/password, unless the app makes their own script in their website to receive a token from the service after granting access (then have the user copy/paste it from your website)
Am I missing something here?
Desktop applications can and should use a user agent (browser) to do OAuth and that is described in the OAuth 2 spec under "Native Applications". The flow you described is meant more for devices with limited input capabilities like a gaming console, printer, camera, etc.
AFAIK, the device flow was in the early specs of OAuth 2, but was omitted at some point. Some API providers like Google have implemented limited support for it regardless.
Native applications are the way to go. See the ["Native Applications"][1] section of OAuth 2.0 RFC. The native applications are not intended to store passwords. If you want to avoid entering of credentials directly in the app (even within a browser control), you may do the following from the OAuth 2.0 native application:
Launch the default browser with the authorization endpoint.
Implement a simple web page for your redirect URI, which picks the authorization code and shows it to the user.
Ask the user to copy the code and paste it back in the native application.
Alternatively, the spec suggests that you leverage the URL redirection scheme of the native platform to bring back the original application. You may check iOS and Android's "URL Scheme" capabilities. Unfortunately, neither of these platforms guarantees uniqueness of the URL scheme, hence the authorization code may be hijacked by another rogue app, which is activated on the same URL. I have filed an iOS bug for that.
[1]: https://www.rfc-editor.org/rfc/rfc6749#page-52
Currently we are not using OAuth with our apps but we are working on making the shift, we have direct login and capture the user/pass that was entered and store those. We then turn around and use the stored credentials for a feature that allows the user to open a record within Salesforce.com, we pass the user/pass in to the login endpoint along with a starting URL to the specific record, this works great and is a well liked feature as it is a simple SSO from the App to Salesforce.com where the user can see all data that may not be visible within the app.
Moving to OAuth 2.0 and using the standard webflow, we no longer can capture the user/pass, which is actually a good thing as far as security is concerned. We would however like to keep this functionality, is there anyway of SSO'ing into Salesforce.com by passing along one of the OAuth tokens or some kind of sesson id?
After reading more and thinking about what OAuth accomplishes I feel like this probably isn't possible being that the tokens obtained are meant to be used only with the API and not with the front end system. I hope that I am wrong though and there is a way to login to the front end using these tokens.
EDIT
Ok I am editing to hopefully make this more clear. Currently user's authenticate using the login() API method with their user/pass, we store this user/pass locally (not ideal). We then sync a subset of data that the users can access anytime within the app, being that it is a subset, we have a feature to "SSO" to the Salesforce.com front-end. This simply opens Salesforce.com in a web-view (UIWebView) using the URL https://ns8.salesforce.com/?pw=PASSWORD&un=username#example.com&startURL=/recordId. This will log us in to Salesforce.com and open the specified record.
Moving forward we want to use OAuth 2.0 with the web flow so that we aren't handling the user/pass and so that we do not have to deal with Security Tokens or opening specific IP ranges to allow login without a Security Token.
With that said, is there anyway to use the tokens/credentials received from the OAuth authentication to open Salesforce.com, automatically log the user in, and goto a specific record?
I may have mis-used "single sign on" before, but in a sense, this simulates an SSO from our App to Salesforce.com, in that our users can touch a single button within the app and be logged in to the Salesforce.com web interface.
When you request an OAuth token, you can specify what scope it has, options include api only (the original type of tokens), or other options which include the ability to use the token with the UI pages. (see the scope parameter detail in the help). One of the still missing peices is a way to bootstrap the UI with that token when all you can do is tell a browser/webview to goto a URL, but a widely used (but unsupported) way is via frontdoor.jsp, e.g. you'd open https://{instance}/secur/frontdoor.jsp?sid={the_Access_token}&retURL={optional_relative_url_to_open} remember to URLEncode the 2 values.
So I think you are saying your application uses the SFDC username and password to just authenticate to retrieve a record from SFDC to display in your app?
IF this is correct - which I think it is - then you could just use the standard Salesforce Single Sign On system to authenticate. There is a guide here which outlines the process of setting up a SAML SSO system with Pat Patterson writing an interesting feature on how the security system works here. He has also written a great blog post on DeveloperForce here about the nitty details of OAuth in general for Force.com and not just the SAML setup. I have used the OAuth system in an iPad app against SFDC and it works quickly and easily. I can't see why your system should be unable to use the protocol as you desire.
Direct access into Salesforce is a key benefit of SSO and definitely provided. I'm not sure where you read that SSO in Salesforce is API only. From the SSO PDF pbattisson linked for you:
With single sign-on, users only need to memorize a single password to
access both network resources or external applications and Salesforce.
When accessing Salesforce from inside the corporate network, users are
logged in seamlessly, without being prompted to enter a username or
password. When accessing Salesforce from outside the corporate
network, users' corporate network login works to log them in. With
fewer passwords to manage, system administrators receive fewer
requests to reset forgotten passwords.
OAuth 1 & 2 are both supported, though I'm a fan of OAuth 2 since 1 has really finicky additional steps involving the order of parameters and their encoding sequences. I recently wrote an Apex-Twitter integration and quickly realized it wasn't going to be as easy as Facebook, which uses OAuth 2.0.
But in your case it sounds like you just want to provide users with the ability to actually login to Salesforce and go to a specific landing page once authenticated. This is definitely doable.
Good luck!