I work for a company where we give customer (hundreds/thousands of users) access to 2 sites. One owned by a 3rd party SaaS and one owned by us.
Customers spend alot of time registering for both sites and we also spend alot of time removing accounts when customers no longer need access.
I would like users to register for Site A. After successful authentication; a user can click on a link within the site to access Site B but without the user entering credentials.
I want Site A identity to be used to access site B and its resources. I do not need site B resources to be presented on Site A site, but simply allow users to access site B if already authenticated to site A.
Users may have different roles on site B.
What is my best option? Oauth2 sounds like a good option. But will it satisfy my requirement above?
Who will manage the authorisation server? I presume Site B?
Thank you.
Two main options:
OLD TECH WITH COOKIES
Perhaps the cheapest option is to use hosting domains and have 2 apps like this:
mail.google.com
drive.google.com
Use a cookie issued to the parent domain, google.com
Cookie identifies user, to provide a user id
Rights are looked up in each app from the user id
OAUTH2 AND OPENID CONNECT
This is the option for modern apps and they are usually used together, due to being web, mobile and API friendly.
It is a big job though, including user migration, and usually involves giving users a new password. So it needs to be something your company are prepared to invest in.
The Authorization Server (AS) becomes a shared central resource and it is common to use a Cloud Provider to ensure high availability.
RELATED RESOURCES OF MINE
Initial Code Sample with Cloud AS
User Migration Blog Post
Related
Assume my company is offering 2 applications, say Mail and Calendar.
Both applications are using OAuth 2 to secure access.
Now Calendar wants to access data from Mail. If those were applications from two different vendors it would be natural for Calendar to ask the user to authorize it's access to Mail etc.
But since the applications come from the same source I'd like them to be able to share data without the user having to explicitly give permissions.
Or to put it differently: I have ID/Access/Refresh tokens for Calendar. How can I exchange them for an Access Token for Mail without bothering the user?
How can this be done in OAuth 2? I control both the applications and the Identity Provider.
The only solution that comes to my mind is for both Mail and Calendar to be the same Application, but that doesn't seem right (and has other issues, e.g. if you want to restrict someone's access to one of them). I could also implement special access outside of OAuth 2 but that is even worse.
A real world example would be Gmail and Google Calendar. They both present OAuth 2 interface to the outside world, but you don't have to allow them to talk to each other.
PS. References to white papers or cases studies would be appreciated
SEPARATED CLIENTS
By default in OAuth you would register multiple clients which get their own tokens. You would then use Single Sign On when navigating between them the first time:
Client ID: app1
Scope: openid scope1
Redirect URI: https://app1.mycompany.com
Client ID: app2
Scope: openid scope2
Redirect URI: https://app2.mycompany.com
If user consent is involved the user has more choice this way of how they grant access to their personal assets.
COMBINED CLIENT
You could potentially combine these into a single entry like this. Note that there is usually a hosting prerequisite of a single base domain in order for token / cookie storage to work:
Client ID: combinedapp
Scope: openid scope1 scope2
Redirect URIs: [https://app1.mycompany.com https://app2.mycompany.com]
PROS AND CONS
The first option is cleanest most of the time, since you avoid tokens with access to too much data. The second option can make sense for related micro-UIs that are really a single app with the same permissions.
APIs AND SCOPES
To share data across apps, companies build API endpoints. You can then have multiple apps that each use scopes representing multiple business areas. See the Scope Best Practices article as a starting point for designing authorization. Eg user logs into calendar app with scopes openid calendar mail - and therefore can get mail data also.
I have a single realm with 3 single-page applications and a shared backend. I want to restrict the access to one of the SPAs so that users without a specific role can't log in.
But once you create a user in the realm, he can log in to every SPA client. I can restrict the endpoints of the backend but I don't want to programmatically reject the user in the specific SPA but automatically on the login page.
I tried to use client roles which don't seem to have an effect in this case. The only solution I have found so far is to create separate realms which I think is conceptually the correct way but unfortunately brings up some practical issues, e.g. the administrators of one realm must be able to manage (CRUD) users of another realm which seems fairly unintuitive.
users without a specific role can't log in - it isn't good requirement. How system will known if user has a specific role without log in (authentication)? Keycloak provides Open ID Connect SSO protocol, which is designated for authentication. After successful OIDC authentication is token generated, which may contains also user role. So only then authorization can be applied. So let's change requirement to: users without a specific role can't access SPA, which better fits into OIDC concept.
The mature OIDC SPA libraries offer authorization guard (name can differs, it is some kind of post login function), where authorization can be implemented. Authorization requires to have a specific role in the token usually, otherwise user is redirected to the custom route, e.g./unauthorized. That's the page, where you can say a reason for denying access. Common use case is also customization of the app based on the user roles. For example users with admin role will see more items in the menu than standard users - that's also kind of authorization. Random example of SPA library with authorization guard (I'm not saying that's a best implementation) - https://github.com/damienbod/angular-auth-oidc-client/issues/441
Keep in mind that SPA is not "secure" - user may tamper code/data in the browser, so in theory user may skip any authorization in the browser. He may get access to SPA, so it's is important to have proper authorization also on the backend (API) side. Attacker may have an access to SPA, but it will be useless if API denies his requests.
BTW: You can find hackish advices on the internet how to add authorization to the Keycloak client with custom scripting (e.g. custom scripted mapper, which will test role presence). That is terrible architecture approach - it is solving authorization in the authentication process. It won't be clear why user can't log in - if it is because credentials are wrong or because something requires some role in the authentication process.
You should indeed not create multiple realms, since that is besides the point of SSO systems. Two approaches are possible in your - presumably - OAuth 2.0 based setup:
restrict access at the so-called Resource Server i.e your backend
use a per-SPA "scope" for each SPA that is sent in the authentication request
The first is architecturally sound but perhaps less preferred in some use cases as you seem to indicate. The second approach is something that OAuth 2.0 scopes were designed for. However, due to the nature of SPAs it is considered less secure since easier to spoof.
I was able to restrict users access to application using following approach:
I've created to clients in my default realm (master) i called my clients test_client1 and test_client2 both of them are OIDC clients with confidential access by secret
I've created a role for each of them, i.e. i have role test_client1_login_role for test_client1 and test_client2_login_role for test_client2.
I've created a two users - user1 and user2 and assign them to client 1 and client2 role. But to restrict access to client1 i have to delete default roles:
That did the trick, when i am logging with user2 i see test_client2 and not test_client1 as available application:
But i did n't delete roles from user1 and therefore i could see both clients when i am log in with user1:
Therefore you should use different clients for your applications, assign to each of a client specific role and remove from users default roles and add one releted to specific application.
My company has a website. Let's pretend that it's hosted at http://www.example.com. I have three apps that I need to build for different teams. Users will have different permissions, possibly different OAuth logins, per app. I'd like to host apps on domains like:
http://www.example.com/apps/my-first-app
http://www.example.com/apps/my-second-app
http://www.example.com/apps/my-third-app
My question is can I do this? I'm trying to understand if OAuth tokens are per domain or per app/url. Thank you for your help.
OAuth Tokens are indeed per domain / app / url.
I did read a while back you can create multiple tokens and store those in the db for the time being so that multiple users with multiple roles can use those tokens to do the things they are permitted to in one domain for instance. I cannot really remember where I read it, but once I do i'll get back to you as soon as possible
You should be able to have multiple consumer apps like that. I'm not sure providers would work however.
Each consumer has a unique client ID and secret (and usually a callback url on the provider, github say). As long as each consumer application has a unique client ID I can't see why this wouldn't work - just create 3 applications on the provider and then make you set the callback urls correctly.
I am exploring the possibility of using OAuth 2.0 in future projects.
What I see is that OAuth is built on the concept of [Resource Owner]+[Web Site Client]+[Authorization Server]+[Resource Server]. A lot of the articles and tutorials in the internet talks about using Facebook, Twitter, etc. as the Authorization/Resource Server, which is all cool and good.
What I am struggling to mentally picture is if I am the one who is going to create my own Auth/Resource servers, why will I choose to go this way? What are the scenarios that otherwise may not be ordinarily be achieved through ASP.NET MVCs form based authentication and the [Authorization] attribute model?
Take a look at the RFC 6749 - it talks about usecases. Its good comprehensible RFC.
Usecase verbatim from RFC:
o Third-party applications are required to store the resource
owner's credentials for future use, typically a password in
clear-text.
o Servers are required to support password authentication, despite
the security weaknesses inherent in passwords.
o Third-party applications gain overly broad access to the resource
owner's protected resources, leaving resource owners without any
ability to restrict duration or access to a limited subset of
resources.
o Resource owners cannot revoke access to an individual third party
without revoking access to all third parties, and must do so by
changing the third party's password.
o Compromise of any third-party application results in compromise of
the end-user's password and all of the data protected by that
password.
Read Aaron's article - OAuth2-Simplified
Recently I learnt OAuth with help of Apigee,you can use anything like google API.
Here is my github project oauth20_apigee if it helps checkout.
It depends on what your short and long term goals are going to be. In my opinion, the short and dirty points are:
OAuth 2.0 is typically used to grant an application access to specific resources on behalf of the user which is a great mechanism for allowing 3rd party applications extend your product. So if you're building an API, then this would be great for you.
Likewise, it is beneficial in that it not only enables someone else to extend your product, but you can also extend theirs. For instance, you could create a trusted application for another product, they could link their customer directly to your module (for lack of a better term) without requiring a separate login, provided you support their token format (typically through the use of a federated identity provider)
If you build your application to support 3rd party OAuth authentication, you can improve the user's experience for registering with your site. By allowing them to use their choice of authentication (e.g. google, facebook, twitter, etc), they won't have to enter in a lot of personal information for umpteen millionth time. You just need to take their authentication and collect any additional information you need. Then create an internal account for them and associate their provider with their account
You can emulate single sign on through the use of a federated IDP, again, enhancing the user experience. For instance, if the user is already logged into google, your product can accept the token and simply request additional scope be added to the token without the user having to sign in again.
Implementing your own OAuth provider is a different beast and I'm not sure there's a ton of benefit to it unless you're planning on being the next Facebook or something.
I think there is a lot to gain from using OAuth. I believe that enabling these credentials in your web sites provides a significant advantage because millions of users already have accounts with these external providers. These users may be more inclined to sign up for your site if they do not have to create and remember a new set of credentials. Also, after a user has logged in through one of these providers, you can incorporate social operations from the provider.
However there is always the devils advocate and this article explains why OAuth could be a possible sercurity hole in an application if not implemented correctly:
http://www.thread-safe.com/2012/01/problem-with-oauth-for-authentication.html
My understanding of OpenID is that it provides a way to have one site contain all your identity & peripheral info, but to let other OpenID-compliant (and user-trusted) sites re-use that info for identifying and authenticating the user. Essentially it minimizes the number of logins credentials (usernames & passwords) a user has for the internet.
My understanding of OpenSSO is that it allows you to sign-in to one site and automatically log-in to all other sites that the first site trusts. Essentially it minimizes the number of times a user has to log in to these different sites.
My understanding of OAuth is that it allows users to grant 3rd party sites certain access to their information located at one particular site. Essentially, like OpenSSO, it minimizes the number of times a user has to log in to these different sites. The different with OpenSSO is that OpenSSO logs the user into all the participating sites at once (with full privileges turned on), whereas OAuth grants finer-grained access to these participating sites.
So, first off, if anything I have said is incorrect, please begin by correcting me!
Assuming I am more or less correct, then I have the following questions/need clarification on the following items:
When would I choose OpenSSO over OAuth - just when I want to restrict access that the other participating sites have when a user logs in to one of them?
Are their different security risks for each of these technologies that I will have to consider and integrate into my app - or are they considered secure in and of themselves (basically can I rest assured that if my app uses them that my app is not open to any new attacks)?
Since these technologies are so closely related its hard for me to see the whole "forest through the trees" here - thanks in advance!
Not really the right comparison to be making. OpenID & OAuth are protocols, OpenSSO (now OpenAM) is an implementation of those and other protocols (SAML, OAuth, etc)
Generally speaking, the protocols for OpenID and OAuth are similar even though they originated with different use cases in mind. Today there is a lot of convergence around OAuth 2.0 for both federation (authentication) and authorization cases. The next generation of OpenID called OpenID Connect is built on top of OAuth 2.0 and precursors to this are already in place at Google, Facebook, Twitter, etc...
As for security, there are always some risks, particularly with implementation errors. Pick a good implementation and read the specs so you understand what the risks and countermeasures are.
OpenSSO is for you to log into one site and be logged into multiple sites.
OAuth lets one site extract your data from a second site (pull your tweets or facebook statuses) without the first site having to know how to log into the second site.