I'm developing 2 Grails applications - A and B - and I would like to support the following use cases
If a user has an account with A, they may also use it to register/login to B (in much the same way as you can use Twitter, Google, etc. credentials to register/login to http://stackoverflow.com). Similarly, if a user has an account with B, it can be used to register/login to A.
Users also have the option to use separate accounts on each site, i.e. they are not forced to use their A credentials on B (or vice versa)
If a user has used their A credentials to authenticate to B (or vice versa) this establishes trust between the 2 sites, allowing A to call an API of B's to retrieve additional information about the user. There needs to be a mechanism that ensures the API can only be called for users that have agreed to share authentication data between the two sites.
Ideally I'd like to use a standards-based approach, e.g. by making each site an OAuth consumer/provider, but I'm not sure which standards are the most relevant standards. If there are any plugins that would help me implement a solution, that would also be useful to know.
I think Stormpath is exactly what you need:
User management API with different SDKs: node.js, express, java, rest, python, flask.
Off the shelf Hosted Login: login, registration, and password reset.
Off the shelf ID Site to power Single Sign-On across your applications
API keys for your users, secured with HTTP Basic Auth or OAuth2
Social Login: Facebook, Google, LinkedIn, Github
Integration with Shiro and Spring Security
Integration with Active Directory and LDAP
In bullet number 3, you are talking about SSO. You can achieve that with Stormpath and Shiro. Please read here.
Disclaimer, I am an Stormpath contributor.
Related
I have a need to implement Open ID Connect in an ASP.NET Core 5 web app for authentication at an organization. I cannot test against the identity provider as this org has their own internal one.
I thought Open ID Connect (oidc) was a standard - yet when I look at docs and sample code for the various providers around, they all either have something provided with ASP.NET or I have to install their package.
For example, to use Google, the ASP.NET Core docs say to use services.AddAuthentication().AddGoogle(). For Facebook, it says to use .AddFacebook().
For Auth0, it wants me to install the package Auth0.AspNetCore.Authentication.
Is it not possible to just add OIDC authentication to my app and have it work with any OIDC provider and just change a configuration file to specify the authority URL, Client ID, Client Secret?
I'm confused about why I need these provider-specific calls and packages.
Architecturally, tieing an app to a single form of authentication is entirely wrong, as you suggest. These packages have limited use, perhaps for very simple use cases.
The original OAuth 2.0 spec from RFC6749, from 2012, describes how the OAuth framework is designed, to externalize difficult security from your apps:
The client only implements a code flow
It redirects to an authorization server (AS)
The AS can authenticate users in a myriad of potential ways, including many identity providers
After authentication (and possibly consent) the AS issues tokens to your apps
Tokens enable authorization in your APIs in a myriad of potential ways
Once you've implemented a code flow in your app, your set of users can potentially login in many ways, with zero code changes in the app:
Password sign in (a default option)
Multi-factor authentication (in a dynamic way potentially)
Cloud platform identity providers (for engineering staff)
CRM identity provider (for client focused staff)
SAML identity providet (for users from business partners)
Webauthn, Passkeys and Digital wallets (for some of your customers)
Unless you have a very good reason, stick to OpenID Connect standards based code flows in clients. You can do all of the above using the Microsoft libraries. Auth0 have good libraries also - just make sure you use the standards based ones.
OpenID Connect is an open standard that organisations use to
authenticate users. IdPs use this so that users can sign in to the IdP
From this blog.
And about the OIDC protocol, it allows you to authenticate users, and is designed for users to sign in many websites with only one account, usually it's a social/work account. This is only a protocol and you have to use an implement such as Google/Azure authentication to allow your users to sign in with their specific account.
By the way, since the implements are from different companies, so the configuration in our codes are different and they required different nuget packages like Microsoft.Identity.Web. For example, when using Azure, we need to set such as client id, client secret, tenant id, domain, redirect url... in appsettings.json.
I'm building a web app using Clojure and ClojureScript and I need it to have authentication based on a white-list of organization. For example, let's say I've added University1.edu to my white-list, and when a student from that university wants to login to my web app, they would be redirected to their own universities login system. After that I would just a confirmation of whether or not they successfully logged in there and maybe create a session, cookies, or or something for them.
Is that possible and if so, how can I implement that?
Some common ways to implement this authentication schemes are OAuth2 and OpenID, which are commonly used in websites were you can log in with your social / Twitter / Facebook / Google account.
Using OAuth for instance, you register your website in some developer portal (depending on the service that you'll use to authenticate) and obtain a token that that you'll use during the login flow and after logging on their portal, users are redirected back to your site.
In order for this to work, every organization (eg. University1) needs to be a provider of this authentication scheme, so that's something you'll need to research.
In Clojure there is a couple of options: the buddy library seems to be a popular choice, but you could also use some Java libraries through interop.
We have several apps Deployed on Google Apps Marketplace using OAuth 1.0 protocol. According expiration OAuth 1.0 in Google Platform we are trying to migrate all the apps to new OAuth version but we are facing some difficulties regarding background request to Google Admin SDK Directory API.
In our apps we need to request for Domain user accounts, groups and other stuff related Email Domain structure. Until OAuth 1.0 we have been doing this with 2-LO (Two-Legge OAuth) so basically once Admin gave us access we can impersonate request for domain using this mechanism.
After reading all Google Documentation about Google API, Oauth Mechanisms and stuff, and after trying some code test hypothesis too, we haven't figured out yet how can we managed the same concept with OAuth 2 because of the following:
Using Web Server Oauth 2 Strategy simply will not work because in that scenario we would be getting a Domain user Access to Admin SDK. If we keep their access/refresh token pair to later querying Admin SDK and the user is deleted because Domain change it Admin we will be disconnected from flow.
I supposed in that case the best choice was Service Account strategy. The problem with this scenario is the user has to manually configure access to the App in their Admin Console according to the Google's document domain-wide delegation authority (https://developers.google.com/+/domains/authentication/delegation#create_the_service_account_and_its_credentials). This is really awkward for us since we were managing all application installation interactively and we don't want to remove User Experience facilities.
Finally, my questions are:
Is there any way to do domain-delegation authority with OAuth 2 with no manual user configuration, full interactively?
Is there any way to do this without needing user email, which in fact is one of the parameters in Service Account Oauth2 Strategy?
Must we keep 2-LO Authentication for this scenario and do OAuth 2 only for installation Google Marketplace part?
Any comments or guide will be wellcome.
Best,
Certainly - in the latest update to the Google Apps Marketplace, the act of installing an App means the admin doesn't need to do an additional manual step.
You need a way to impersonate a user in a Service Account. Depending on how you implement your application, you might need to utilize the Directory API.
OAuth1 is going away eventually so I recommend you use OAuth2 throughout to simplify your code complexity.
What is the best/proper technique to share login between two sites.
I have website A, and some websites B. Both types belong to the same company, but B is running on the customer premises. What I would like, is that users login in B, and when redirected to A for some reason, they don't need to login again, and they can work with their account in A.
Of course, the company will make logins for each 'B' user. The problem is that the user could initiate the login in A or B.
Would OAuth do? Or OpenID would be more suitable?
Another option is pass a GUID token in the GET string, with a sort time to live and only valid for the IP address of the requester, but it is not sure the user would access the web sites through the same gateway.
Thanks
OAuth is exactly what you need. OpenID offers discovery which is only useful when the user gets to choose who to authenticate with (not your use case). Also, OpenID is much more complicated and is a dying protocol.
In your scenario, Server A is the OAuth server (or authorization server in OAuth 2.0) and Server B is the client. There are many ways to implement this, but I would suggest you start by looking (and trying) how Facebook OAuth 2.0 implementation works. It will give you a good idea of what is involved and some of their extension (e.g. display) which make it more user-friendly.
You are talking about single sign-on. Does the company who owns Website A provide remote sign-on in their api?
You need to make sure that the log-on information is encrypted when it is passed to website A. The last single sign-on I built required me to pass the user's AD name encrytped via RSA and hashed with MD5. The third party had a database of the user's AD name and their password to the third party site. When the user clicked a link, their encrypted information was sent to the log-on api of the third party and the third party redirected them to the welcome page with the log on process complete.
If you are building a single sign-on API yourself, as in you have control over website A, OAuth is a respectable choice. It is fairly easy to impliment.
What's the difference between SAML and federated login with OAuth? Which solution makes more sense, if a company wants to use a third-party webapp, and but also wants single sign-on and be the authentication authority?
They solve different problems.
SAML is a set of standards that have been defined to share information about who a user is, what his set of attributes are, and give you a way to grant/deny access to something or even request authentication.
OAuth is more about delegating access to something. You are basically allowing someone to "act" as you. Its most commonly used to grant access api's that can do something on your behalf.
They are two completely different things.
Some examples that might help out.
OAuth think of an twitter. Lets say you are using Google Buzz and Twitter, and you want to write an app to be able to keep the two synchronised. You basically can establish trust between your app and twitter. First time you go to link the app to twitter, you do the classic prompt to log into twitter, and then that confirmation box pops up and asks "Would you like to grant access to «your app name»?" once you click "yes", the trust has been established, and now your app can act as you on Twitter. It can read your posts, as well as make new ones.
SAML - For SAML think of some type of "agreement" between two unrelated membership systems. In our case we can use US Airways and Hertz. There is no shared set of credentials that can take you from one site to another, but lets say Hertz wants to offer a "deal" to US Airways. (Granted I know this is an extreme example, but bear with me). After buying a flight, they will offer a free rental car to its Chairman members. US Airways and Hertz would setup some form of trust, and some way to identify the user. In our case our "federated id" would be the email address, and it would be a one way set of trust Hertz trusts that US Airways identity provider will deliver a token that is accurate and in a secure manner. After booking the flight US Airways identity provider would generate a token and populate how they have authenticated the user, as well as "attributes" about the person in our case the most important attribute would be his status level in US Airways. Once the token has been populated it passes it via some type of reference, or encoded in a url and once we get to Hertz, it looks at the token, validates it and now can allow for the free rental car.
The problem with this SAML example is it's only one specialized use case out of many. SAML is a standard and there are almost too many ways that you can implement it.
Alternatively, if you dont care about authorization, you could almost argue that asserting authentication via SAML and OpenID.
Have a look at this simple explanation summarized here:
Many people are confused about the differences between SAML, OpenID
and OAuth, but it’s actually very simple. Although there is some
overlap, here is a very simple way of distinguishing between the
three.
OpenID – single sign-on for consumers
SAML – single sign-on for enterprise users
OAuth – API authorization between applications
For folks comfortable with OO design patterns, I think there's a nice corollary to wrapper patterns. Think of Facade, Decorator and Proxy patterns. Fundamentally these are all the same, they're just wrappers... The difference is the intention of each pattern.
Similarly, SAML, OAuth and OpenID all facilitate different intentions via a common underlying mechanism, which is redirection to a service provider/identity authority for some private interaction, followed by redirection to the originating third party app.
Looking around on the net you will find overlap between the protocols' capabilities. Authentication via OAuth is perfectly reasonable. SSO over OAuth may not make a lot of sense though as SAML and OpenID are specifically geared towards federated identity.
To the question itself, in a corporate context SAML sounds more appropriate than OAuth for SSO. I'd bet if you look at the third party apps you'd like to integrate with your corporate identities, you'll find they're already designed to integrate with SAML/LDAP/Radius etc. IMO OAuth is more appropriate for Internet interaction between applications or perhaps applications comprising a Service Oriented Architecture in a large corporate environment.
Authorization rules may be specified in a corporate environment in other ways too. LDAP is a common tool for this. Organizing users into groups and associating application privileges against group membership is a widespread approach. Just so happens LDAP can be used for authentication too. Active Directory is a great example, though I prefer OpenLDAP.
Found Good article here
SAML (Security Assertion Markup Language) is set of standards to achieve Single Sign On (SSO), Federation and Identity Management.
Example : A user (principal) authenticates with a flight booking website, AirFlyer (identity provider) which has SSO configured via SAML with a shuttle booking website,Shuttler (service provider). Once authenticated to Flyer, the user can book shuttles on Shuttler without requiring authentication
OAuth (Open Authorization) is a standard for authorization of resources. It does not deal with authentication.
Example : A photo sharing mobile app (OAuth consumer) that allows users import photos from their Instagram account (OAuth provider) which sends a temporary access token or key to the photo sharing app that expires after some hours.
They handle a subtle use case
SAML - Sharing credential (e.g., SSO) of a user to various service providers (e.g., web or web service)
OAuth - A User delegating an App to access a resource on behalf of his/her
SAML has a variety of "profiles" to choose from allow other users to "log in" to your site. SAML-P or SAML Passive is very common and fairly simple to set up. WS-Trust is similar and it too allows for federation among websites.
OAuth is designed for authorization. You can read more here:
What's the difference between OpenID and OAuth?
SAML is for authentication - mainly used in Single Sign On scenario. OAuth is for authorization of resource representations.
JSON Web Token (JWT) is an alternative for SAML XML Tokens. JWT can be used with OAuth
A good reference is SAML vs. OAuth: Which One Should I Use?
The terms federation really means connection identities across systems. It's related to SSO but they aren't quite the same. I Found this blog post really helpful in terms of what federation really means.