How can I make my desktop application into an OpenID relying party?
Have a look at this question, it looks to me that OAuth can do this for you.
Since OpenID has a specified protocol, it will either work all the time (assuming providers are conforming) or not at all. Additionally, since the OpenID protocol (at least the authentication bits, see the specification) consists of simple HTTP requests, you could implement the protocol in a desktop application assuming you know how to make such requests.
It is generally considered a bad idea though, since there are better technologies (OAuth) and it disrupts the user experience (being different from OpenID in a browser — see OpenID For Desktop Applications: How? When?).
Further reading: OpenID for Desktop Clients
Don't do it.
Even an attempt to do so shows a fundamental lack of understanding in the security model that OpenID offers. You have to ask yourself what the password that you would otherwise use for your desktop app is protecting. Is it protecting assets on the local machine itself? If so, OpenID is useless because it would be a simple matter to spoof the network such that I could hack my way into the desktop app without owning the OpenID. You're wide open to user identify spoofing. Are you trying to protect network assets? OpenID fails again, since it doesn't authorize your desktop app to access those network assets, suggesting that some other authentication is going on behind OpenID so once again you're not adding any value.
OAuth is the protocol suited to allow your desktop app to access and protect network resources. If you're protecting local assets on the desktop computer, local encryption is the only way to go.
It seems to me that you should present a small web browser window for the authentication to be completed. The interaction would not be going through your code.
I would not suggest using web scrapers to do this. In doing so, you place your code in between the user's server and the user, which is a breach of the covenant that the user's password is not seen by the relying party.
OAuth is the right technology to use for a desktop application, but it doesn't use the existing password ecosystem that OpenID has, which was not a part of the OP's question.
Related
I have a public-facing application that uses ASP.NET Core Identity to store first-party logins, and no intention of using third-party IdPs like Facebook or Google. I want to build the front-end in React, and the application comprises an API fronting a couple of back-end services to which I'll need to forward JWTs for authorisation.
The plan so far is to use Identity Server 4 as the IdP for the project, backing it into the ASP.NET Core Identity data stores.
Current guidance is to use Authorization Code Flow with PKCE, which would require redirection to the IdP, two sets of styling etc.
In this scenario, where there is no possibility of a third-party IdP, is Resource Owner Password Grant still highly discouraged? On the face of it, it gives a neater experience:
User populates React-based login page
XHR POST to IdP with credentials (modulo an MFA challenge)
IdP returns an access token, React app subsequently uses that for future requests to the API
What issues will I introduce by pursuing the ROPC grant in this specific situation, vs accepting the need and duplication involved in a redirect-based flow to the IdP?
AMOUNT OF WORK
This is one of the big issues. As well as a login screen you'll have to make sure other areas such as Forget Password also work. If you build a second app you'll need to make it work there also.
EXTENSIBILITY
This article summarises problem areas. One of these is no scope to ever extend login solutions.
SECURITY
Token refresh does not (usually) work with ROPG, which leads to long lived access tokens and other complexity. Also, with OAuth it is recommended that the app never sees credentials.
From a security viewpoint it looks more modern to redirect the user - all the big providers do it - eg Google, Microsoft.
BRIDGING SOLUTION
As you say, if the password is private to your app it may not be the worst thing in the world. Capturing a user's Google password in your app would be a bad thing though.
ROPG has its uses but does not have much of a future - it is deprecated in OAuth 2.1 and providers will be getting rid of it. So I would also recommend what LalitaCode suggests ..
You can create a React based Identity Server login page for Authorization Code flow with PKCE instead of using MVC UI if you want. It is just extra work and complicated. I would recommend you just style the Identity Server MVC UI to look exactly like your frontend SPA. This is the simplest way and the path I took when I did a project with Identity Server(with Angular as front end).
One of our clients requested that we integrate our system with ADFS (Active Directory Federation Services) while another requested that we integrate with Okta. They want the experience to go something like this: the end users opens up the Windows app (on their domain joined computer) and is able to use it right away with implicit authentication from one of those identity providers. No extra clicking or registration. I am willing to create multiple copies of the application integrated into these different identity providers if necessary.
Our current setup uses Node/Express as a backend (hosted on amazon web services) and all traffic is sent through this API. Our client interface is a wpf Windows application. This seems to be a less common setup. Currently, the user must sign up with an email and password, and must log in using that same email and password to start using the application.
There are 3 parts to this question that I'm super confused about (I'm an intern with limited knowledge, so please explain like I'm 5 if possible). On the other hand, I believe I have a solid understanding of how Single Sign On conceptually works (with us being the service provider and ADFS/Okta being the identity provider). Even if you can answer parts of these questions, I would be super grateful!
What (if anything) do I have to do to our API backend? I'm assuming everything just needs to be done through the windows client right? But then I saw a passport saml package but I'm unsure if I need it to complete this task.
What do I have to do to our frontend? I've tried one of auth0's sample windows application but it seems like everything is still going through a login screen. At least for any social media connection. We'd like to ideally do this without a login screen and hopefully without proprietary software like Auth0 (since we manage our own user database already). We just want something so that at startup of our wpf application, the application queries for user's information (through ADFS or Okta) and then all behind the scenes, the user is logged in automatically. Any pointers here?
What I do have to do on the 'main' active directory Windows server side (this would be on a client's enterprise network)? I've seen hints of setting up callback urls, certificates, metadata, and something, but I'm unsure of what all of that is. Lots of questions just reference that but don't explain what or why it's needed?
Lastly, I apologize if any of the questions are vague, I have tried to do research, but it just seems like all the pieces are either too advanced or just don't apply to my setup. Thank you for your time!
ADFS etc. rely on federation protocols like WS-Fed and SAML 2.0 and so the IDP behavior is determined by the protocol.
There is no browser based functionality to just log you in.
You will always be taken to an IDP login screen. Once you have authenticated, other applications on the same IDP won't require authentication. They can seamlessly log you in based on cookies.
You can't query for user info. until you know who the user is.
On the ADFS side, you can manually configure a RP (your app).
I was just playing around with OpenAM and found that authentication can be done through SAML as well as cookie based approach of CDSSO. Now my concern is if I am working in domain like banking and healthcare how feasible it would be to go for CDSSO cookie based approach and is their any organization who is practicing cookie based approach in any such domain.
SAML is designed for connecting independent security "domains". The term "domain" in this instance has nothing to do with network domain names, but a rather more nebulous term, meaning a division between security systems. An example to explain a bit better: Company A uses OpenAM to protect its intranet websites, but they also use services from Salesforce. SAML is the obvious choice here - Salesforce isn't going to use a cookie from OpenAM... How could they? You could also use it to interconnect two different systems inside a company (and domain name), like OpenAM and Siteminder, since those two systems can't communicate directly via their cookies.
CDSSO is primarily designed for use inside an organization that could have multiple domains that they protect. They can have multiple policy servers in multiple domains, but all of those servers are managed by the same OpenAM instance, and they all share a common backend. Lots of organizations use OpenAM's (and OAM's, and Siteminder's) CDSSO capabilities. But they use it inside the systems within their control.
In addition, I can't think of a single service provider that would want you to place one of your OpenAM policy servers inside their network. You wouldn't want them touching your server, and they wouldn't (if they are right in the head) trust you to not be dropping a trojan in their network.
TL;DR:
SAML - outside of an administrative domain
CDSSO - inside an administrative domain
SAML is the standards based way of achieving SSO for, Agents is the proprietary way.
SAML does not offer any authorization (which user is allowed access to a given resource) out-of-the box ... that's the backdraw.
Currently have an client application running on GAE that supports OpenId login to access resources on a server application (also on GAE) through OAuth. All is fine.
But, it requires that the user have an account with Google, Yahoo, or other OpenId provider. While that seems fine for personal users, how do I handle the corporate case where users want to use myname#mycompany.com as their login?
Do I build my own OpenId provider, host it, and store those names/passwords in a database?
Is there existing OpenId source that I can use, but give it my own names/passwords?
Do I skip OpenId entirely and somehow get my own custom db lookup to integrate with GAE authentication?
Something complete different?
My work is in Java, so Java solutions are preferred. And since this is more for prototyping than for production use, easier solutions are preferred :).
After doing some additional research it seems that if I want to stick with my current use of Restlet's GAEAuthenticator then I will have to rely on OpenId. There appears to be ways to rewrite the entire authentication so that it works both with Google/OpenId and a custom database (not what I want to try), and there appear to be commercial products (SadaSystems) that seem to also do it.
For now, my workaround is to ask people who want to use their own email address in our system to sign up with MyOpenId and add that email address as their persona.
Currently I'm developing a GAE application in golang that would allow the users to log into the service using OpenID from Google. Each account would be mapped to one Google account obviously. Should I implement captcha for user registration, or does using the OpenID already prevent the service from a bot attack?
Are you accepting any OpenID? Then this is not sufficient protection. Anyone can put up an OpenID site on their own domain, use a script to create a billion accounts, and log in with one of them on your site.
Are you accepting only specific OpenID providers? Then you're not using OpenID as it was meant to be used (and, in fact, expressly the opposite of why it was created). But the answer then would be: do you trust that the OpenID providers have done their own due diligence at the time of account creation to prevent spam accounts?
Regardless, you'll likely find that captcha's a poor solution, and currently all implementations of it are broken (but that's a whole different topic).
First of all, fear of a bot attack is really a preliminary caution. Parsing CSRF tokens (which you should use anyway) and dealing with cookies would already cause enough pain to an attacker. I doubt anyone would trouble himself into setting up very own OpenID provider which is the only way one can do that.
Secondly, App Engine's OpenID Federated Login is the User API feature, not Go runtime's one — you can use any OP with it (Facebook, Yahoo!, Steam... Google). User API provides two modes (configurable via Application Settings): OpenID Federated Login and Google Accounts sign in. Which to pick depends on requirements. If all you need is user's Google account you'd better use the latter, when if it's simple password-less sign in with nearly everything, choose OpenID. From the app's perspective both look identical. Best way to go is OAuth, though.
Getting back on the question, both Google Accounts API and OAuth would make such attacks almost impossible and with OpenID it is a little simpler.
https://developers.google.com/appengine/docs/go/users/overview