This is a conceptual challenge that I'm trying to wrap my mind around. Let's say I have an SSO (single sign on) service and two separate web services that use it. Let's say that the SSO login happens via OAuth, just like Login with Facebook. (Correct me if I'm wrong that they're not just requesting an OAuth access token for the site in question.)
The question is then, how should the two web services expose their own APIs to third parties? Given that we've drunken the OAuth kool aid, it seems logical that the third parties should be considered OAuth consumers and they should request that the user approves an access token for them. Accepting that the question is, should the the web services handle all this OAuth stuff themselves, having the third parties register as OAuth consumers with them and only using the SSO to login the user? Or, should the web services hand all responsibility off to the SSO service? For signed requests, the web service would check the validity of the access token via the SSO's API and then process it as normal.
I see pluses and minuses to both approaches. On one hand, the first option places fewer demands on the SSO and each web service can handle the authorization for their APIs their own way. On the other hand, having the SSO handle things means that the third parties can get access tokens that are valid across all the services, just like how users can login across all of them.
This can enable a better user experience, as otherwise the third party might have to keep asking the user for authorization as it needs to use different web services of the system, despite the separation between the different web services being invisible to the user. Of course, then either the SSO needs to have some sort of shared permission rules or each web service will still need to enforce its own rules. Also, the SSO would probably have to take some sort of text or HTML from the web services to display when asking the user to authorize the third party service.
Any suggestions? Are there any existing, publicly documented systems that do this well? Am I just over-complicating the whole thing?
Related
I'm struggling with these concepts and having trouble finding good resources on the web.
We are looking for ways to switch out custom implementations tightly integrated into our application for standards based authentication and authorization.
Our scenario is as follows:
A simple web site (may be an app in the nearby future)
A user must log in or otherwise gain access (i.e. there's no "guest" content or other things you can do as a guest)
The site uses its own web services (REST and/or SOAP) on the backend, but it might use 3rd party web services or exposes its own services as 3rd party services for other applications
Authentication may very well be done by an external provider: Users carry a smartcard and we'd like to have one simple identity provider which reads the smartcard information and sends it back to my simple web site (so I know who the user is and what his role is for instance)
Other sites might use other methods of authentication (simple username/password for instance), so we might need a configurable Service Provider??
I'm currently looking at OAuth (2) to implement for authorizing use of our REST Services (is it also useful for SOAP?) to our web site, perhaps with a simple "Client Credentials Grant" type.
But for authentication, I'm still none the wiser. There is OpenID, but is it easy enough to build your own OpenID Identity Provider? There is Shibboleth, but it seems to have a steep learning curve for doing custom stuff. And I've looked at just building something from scratch based on the SAML Authentication Request Protocol with an HTTP Post binding. Are there any other options?
Please keep in mind that we want to be flexible with our authentication. For a certain site, we might want to do the smartcard thing, but for another maybe simple username/password login with LDAP.
If it's helpful still, I personally thought about doing it myself, then discovered a bunch of third parties. I compared (5/18/2015):
Auth0
AuthRocket
UserApp
DailyCred
Conclusion for me was Auth0, because while all the features are very similar, it felt the most legitimate, as in it's not a start-up that might disappear in a few months. Now, the reason that was super important for me was because login is a foundational requirement, so I need to believe as a customer that the Authentication as a Service will be up for as long as I will be.
Here's the full comparison story:
https://medium.com/#bsemaj/authentication-as-a-service-comparison-5-quick-lessons-for-b2b-businesses-e7587275824c
Updated based on questions from #user18044 below
If a user is authenticated in two different web applications via 2 different SAML-based identity providers, and one of the applications needs to request data from a web API exposed by the other application, would it be possible to call the web API methods securely by virtue of the user's current authenticated status in both applications without separately securing the API methods via an API level authentication protocol such as OAUTH? Note that both applications are owned and operated by my company and share the same 2nd level domains and user base, even though the identity servers are different (one is legacy).
Some further information: Application A is a portal application that is going to host widgets using data supplied from Application B. Application A will only communicate with application B via a web API exposed by application B. Currently application B does not expose a web API (except internally to the application itself). This is new functionality that will need to be added to application B. Application A will use Okta as its SSO. Our lead architect's proposal is to continue to use a custom legacy IDP server that we developed internally based around using the dk.nita.saml20 DLL. They are both SAML based I believe, but I don't think they could share the same identity token without some retrofitting. But this is hitting the limits of my knowledge on the topic of authentication. :) I think our architect's plan was to have the user authenticate separately using the two different identity providers and then only secure the web API using CORS, his reasoning being that since the user is already known and authenticated to use application B, that there wouldn't be any security implications in allowing application A to call application B's web api methods, as the user should be authenticated in application B. This seems quirky to me, in that I can imagine a lot of browser redirects happening that might not be transparent to the user, but other than that, I'm just trying to figure out where the security holes might lie, because it feels to me that there would be some.
I know that this approach would not be considered a best practice, however with that being said, I really want to understand why not. Are there security implications? Would it even work? And if so, are there any "gotchas" or things to consider during implementation?
To reiterate, our lead architect is proposing this solution, and it is failing my gut check, but I don't know enough on the topic to be able to justify my position or else to feel comfortable enough to accept his. Hoping some security experts out there could enlighten me.
It's hard to answer without knowing more on how your current applications and APIs are secured exactly. Do the web application and its API have the same relying party identifier (i.e. can the same token be used to authenticate against both)?
If both web applications use the WS-Federation protocol to authenticate users, then most likely the SAML token will be stored in cookies that were set when the identity provider posted the token back to the application.
You do not have access to these cookies from JavaScript. If the web API that belongs to application B uses the same cookie based authentication mechanism, you could use this provided you allow for cross origin resource sharing.
If your web API uses something like a bearer token authentication scheme (like OAuth) or has a different relying party id in the STS, this would obviously not work.
I think the reason this fails your gut check is because you are basically accessing the web API in a way a cross-site request forgery attack would do it.
A problem I see with this approach is that if the user is not authenticated with the other web application, then the call to your API will also fail.
I agree with user18044 as far as it being based on a cross-site request forgery attack and the security between applications. Is it true that if User X has access to App A, that they will have access to App B and vice versa? If that is not the case, then each application will need to be authenticated separately...and it won't be a SSO. I found these links that might be helpful in your situation.
https://stackoverflow.com/questions/5583460/how-to-implement-secure-single-sign-on-across-various-web-apps
https://developer.salesforce.com/page/Implementing_Single_Sign-On_Across_Multiple_Organizations
I am working on an internal authentication system for users of a set of of RESTful web applications. Our intention is that a user should be able to sign-on once via a web form and have appropriate access to all these RESTful applications in our domain, which may be distributed in a private cloud across many servers. (I understand already that having a single authenticated session is not aligned with a pure RESTful approach, but this is a usability requirement.)
The applications themselves will be written in a variety of programming languages so a language-neutral approach is required. It was suggested to me that we might use OpenID or OAuth or a similar framework to handle the authentication but my understanding is that these are intended for third-party services and not the first-party services that would share data on our internal system. In this case, we might have a central provider service with all the other applications treated as third parties (or relying parties).
Questions:
Are OpenID/OAuth suitable for authentication among first-party services?
If so, how would one be advised to set up authentication for this use case?
Wouldn't a user have to grant individual permission to each first-party server that they wanted to use, just as they would need to grant individual permission to any third-party server? I think this would violate the requirement of having a single sign-on for accessing all the first-party services.
Are there good examples of sites supporting this first-party use case?
What would be a good alternative framework for this first-party use case?
You do not need OAuth for SSO services.
The primary use/advantage of OAuth is, as you know already, granting access to a 3rd party app to access/use your resource in a controlled manner.
Rather than having an authentication/authorization server that you would need for OAuth, why not use a single log in service across all your APIs. An OAuth access token is totally different from what you need.
As far as I understand, what you can have is something like OAuth in a way that your server vends out tokens to the app. (I'm assuming that it's a totally internal system, so tokens cannot be misused).
So basically what I'm proposing is:
When an app tries to access the first API it's redirected to a web-form.
The user enters credentials and is taken to the DB for verification. Let there be a service that generates a token for the user/app
Next API access request would be made with that token - the token uniquely identifies the app
Depending on the level of security you need you can sign some text using HMAC and send it as token, or if its totally internal just generate a unique identifier for the app/user and send it to other API
On receiving the token, each service first calls the main server with the token and internally fetches the corresponding customer/user ID and performs the required function.
In short separate the login + token generation + token verification into a different module. All APIs should use this module for login/token verification.
What I have proposed here works like OAuth but all security aspects have been stripped down since you want to use it in a private cloud.
Oauth supports multiple different kinds of flows. You can use the client crendentials flow from Oauth 2.0 to avoid asking the user to grant permission for every app (this is intended for the cases where you control both the server and the app or where you want to preauthorize certain apps). This post does a good job explaining everything: http://tatiyants.com/using-oauth-to-protect-internal-rest-api/
I am starting a new web project and I intend to make it API based; that is I want to build the API first, authenticated via OAuth, then build a website and possibly mobile app(s) that use the API to handle data. I also have my eye on opening up the API to the public.
Here is my issue; I am struggling to get my head around how to authenticate these 'official' apps, the ones made by me, including the main site.
In OAuth the client creates an account for each user then seeks access rights via the resource owner logging in at the main site. This obviously does not work for me because the main site and the client are the same place and it also implies my users should be creating two accounts just to use my website...
I believe twitter uses its own API to run twitter.com and I get the impression that this approach is becoming quite normal so there must be a standard approach.
I must be missing something, but what?
You are confusing the API (business logic) with the authenticaton of user identity (for example logging in), and the authorization of third party apps (OAuth).
It is correct that twitter.com uses their own API. But they don't use OAuth on their own site. When you're on twitter.com, their APIs are available to themselves over cookie authentication. To put it simply: you're logged in.
Once you move away from twitter.com you have to use OAuth. Now an application is using the API on behalf of a user.
To sum up. You don't specifically need OAuth for your "own" web client to use your own APIs. You need OAuth, or some other authorization mechanism, to publish your APIs and it will also come in handy for your own "official" apps.
There is really no need to distinguish your own official apps from third party apps. Not from a technological perspective anyway.
Host two versions of the "API". One mapped to the external domain api.yoursite.com and it OAuth-enabled to authenticate all requests. The other internal version is accessible only within your pool of servers, your official apps. Since only your official apps can access it in the first place, consider all requests to the internal API trusted.
If you want the same application to manage both external and internal calls, you can choose to
distinguish external and internal requests based on incoming IP addresses
implement your API to accept one of "VIP passes" or OAuth tokens for authentications. External apps use OAuth tokens to perform actions on behalf of certain users. Official apps use "VIP passes" to perform actions on behalf of any user.
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.