We have a backend (RESTful) service for websites that depends upon uniquely identifying the same user across multiple, unrelated websites. We have been using email address as the unique identifier, but email address is not always used by all websites, especially when OpenID authentication is by those websites.
So, does OpenID provide a unique identifier that would be the same across multiple Relying Parties (if the user authenticates with the same OpenID)?
If so, what would one instruct a series of independent website to provide us as a user identifier for each of their users if the goal was that multiple, unrelated websites provide the same identifier when they each have the same OpenID user?
Also, a goal is to make this as easy as possible for developers that will consume our APIs. So, if you know of any good API documentation that has already solved this, links to that would be very helpful.
Without knowing anything about your web service or what language its written in, I'm not certain how helpful my answer will be as it will be fairly general and less technical.
OpenID providers responding to an identification/authorization request will respond with a "Claimed ID" and an "Identity" as well any "attribute exchanges" requested. The attribute exchange information can be things such as email/username/language/realname/etc that may be what you are looking for.
Google (as an OpenID provider) supports querying a decent number attribute exchange information, and provides a list in their documentation:
https://developers.google.com/accounts/docs/OpenID#Parameters
The OpenID Identity should be unique to a user, but may not cross-identify them to different websites even when issued from the same provider. (It can be a directed id unique to the RP it was issued to).
See more on this here:
is openid.claimed_id static?
With all of this said, it is perfectly reasonable for you, as the designer of the API, to define that certain information (i.e. an email address) is required to consume the webservice. And then leave it to the parties that wish to use your webservice to somehow gain that information (directly asking a user, or through attribute exchange, etc).
For more information on OpenID I would look at their website, particularly the specifications and libraries:
http://openid.net/specs/openid-authentication-2_0.html
http://openid.net/developers/libraries/
Libraries with some good documentation to use as a starting point include:
JOpenID (Java): http://code.google.com/p/jopenid/wiki/QuickStart
LightOpenID (PHP): http://code.google.com/p/lightopenid/w/list
Implementing the OpenID authentication directly would not be applicable for a backend webservice since the end user has no involvement (i.e. could not supply credentials).
To meet your requirement of identifying the same user across various 3rd party websites you may need to become an OpenID provider. And then provide further API to allow functionality on 3rd party websites for users to link into their OpenID profile you manage.
Without being the actual provider of the identity... Sharing the OpenID identity with a 3rd party may be a potential security/privacy concern or in the very least against the specs of OpenID (which describes the exchange as a a shared secret between the RP and OP). Though it may be beyond the scope of what you wanted to do, being the OpenID provider would at least remove many of the privacy issues since the users would have to opt-in explicitly.
I'm not aware of any APIs that handle uniquely identifying users across multiple 3rd party websites without direct user interaction. Most webservices that I have written required either direct user credentials be supplied (for which the user was aware), or had to only identify a user as unique to a particular client. In the later case user authentication is not always necessary, the client could do a blanket authentication and then provide its own unique ID to track users, letting the the webservice be blind to what actually constitutes a user. Your requirements do not appear to fit into these common scenarios unfortunately.
One final thing to consider as you design your API...
Providing uniquely identifiable information (i.e. an email address) to a 3rd party may raise some eyebrows in the internet privacy ring. Especially if there is any financial gain to be had from the exchange (advertisments/directly-paying/etc) or if the use of the information is unknown/insecure or otherwise unwelcome.
http://www.ehow.com/about_5332990_legal-sell-email-list.html
http://www.aclu.org/technology-and-liberty/internet-privacy
You may want to ensure that your target clients (the consumers of your webservice) have the right jargon in their terms or can provide sufficient power to their users that allow them to opt-out of being submitted into your service. And make it clear what you are doing with the information...
Issues like that can be something that holds up acceptance of your API, so it is worth considering.
Related
Suppose I have a working REST API for my product.
I want to give access only to developers who sign up to this product. Also, there will be several plans available so certain parts of the API are not accessible on the free plan.
From the grant types I've seen only the client-credentials one seems to be the closest solution. However that won't authenticate the developer account stored in my product db, it will only get an access token for that client. The user won't actually be 'logged in' per se. Add to that the fact that a single client can be reused by everyone, according to implementations I've seen.
The only way I see is creating a custom grant type, by adding an extra api_key to the client credentials type, which pertains to the developer account.
Is there a way to do this with the existing grant types? Introducing custom types will not work with many oAuth2 libraries out there out of the box and I don't want to give the developers the hassle of modifying them.
I don't think you have to invent a custom grant type.
A single client can be reused by everyone only if everyone knows the client secret.
So, it seems that what you have to do is (1) to authenticate a developer when you issue a pair of client ID and client secret to the developer and (2) to motivate the developer not to reveal the client secret to others.
I have an API which I'd like to secure using OAuth. My API is accessed with a web frontend used by real human users all with their own account (a couple of thousand), and it is also used by the API of some partner companies (less than a hundred), which should also have separate accounts.
I would like to secure the API using OAuth, and I have to decide how to represent the different users. In OAuth, there are two different concepts, clients and users, where client is the higher level concept, and every user is under one of the clients.
I can think of two different ways to represent these API accounts:
Have a single client, and have a separate user for every human user, and for every partner API.
Have one client for the human users, and a separate user for every human user. And have a separate client for every partner API.
Which of the two approaches would be the more idiomatic approach in OAuth? From a technical standpoint I don't see too much advantage or disadvantage of either solution.
(I'm partly confused because the client credential flow is described to be used for API-to-API authentication, which seems to make sense for authenticating the partner APIs. However, most of the OAuth guides also say that it should only be used for trustful APIs (whatever that means), or even internal APIs, but these partner APIs are definitely not internal.)
Implementation will be unified if there is separate client behind every app (including JS one, for users accessing your API via web frontend).
Also it will be possible to manage ACL per app in this case, which will define maximum privileges for the users (users may choose to give less privileges to the app).
On the other hand, simpler approach is to use Cookies for web frontend users and OAuth for partner applications. But in this case you need to support both authentication options.
Call me a newbie, call me dumb, rate down this topic. Do as you like, I'm just here to ask a question and hopefully learn something from it.
So I've been making an API for my website today (well attempting to) and I've noticed this "thing" on most popular sites API's such as Twitter, Foursquare, Tumblr called "OAuth". From my research today I have gathered that it's basically a way of giving the consumer a token to access restricted data from the provider depending on what the user chose without the user handing over their password and username.
But why do I have to use OAuth, why can't I just give out an API to the consumer key and they just use that? I will then see if the user has allowed access for the application, and they will have to grant access for the app to take information from their account, such as photos.
Something that also confused me is why the Tumblr API uses both. It seams on reading blog details they use a simple api key but posting on blogs you need an OAuth Signature.
OAuth is a protocol and has a set of specification defined by some expert group to define how to share data.
Basically what you are seeing is just a part of the OAuth mechanism,and there is a lot of communication and hand shaking mechanism to ensure the security of user data as well avoiding unauthorized access to data.
OAuth mechanism exits at 2 levels
three-legged authentication
Two-legged authentication
Both have their positives and negatives and there are a set of procedure which needs to be taken care for security and data integrity.
Allowing access only based on access_token/consumer key is really a very weak security mechanism and can easily be hacked by any one who happens to get access to your consumer key while OAuth system make sure by sharing a time bound access_token.
For details refer to this thread oauth-2-0-benefits-and-use-cases-why
Why use the proposed OpenID OAuth Extension over another OAuth-based protocol?
Discovery doesn't seem to be a feature. Although the consumer only needs a claimed identifier to start the authentication process, any authorization will still require that the consumer knows the access token URL, signature methods, and have a shared key/secret with the provider.
One benefit is that there's a specified way to ask for specific authorizations, the openid.oauth.scope argument to the authentication request. And one specific benefit for this is that authentication only - for the benefit of the consumer only, with no verifiable token - is defined for free and can be performed without worrying about keeping track of outstanding tokens or the resources they might require.
Are there examples of alternative ways in use to specify the scopes to be requested, perhaps with something in OpenID discovery? Or could this be handled effectively with some kind of REST navigation before the OAuth process, where one of several request token URLs specific to the desired scopes is discovered by interpreting hypertext starting from a well-known URL?
I am researching a delegated authentication and authorization system with several authorization scopes, where the scopes are relevant for different interactions. In other words, the consumer needs to tell the provider which scopes should be presented to the user for authorization.
The OpenID+OAuth extension really has only one significant advantage over standard OAuth:
If you need to authenticate the user and access the user's private data, and the OpenID Provider happens to also be the OAuth Service Provider (the user authenticates with the same service that holds his private data), then the extension will help the user have just one redirect to the OP+SP instead of two separate ones. For the user, this is a huge usability win -- if he happens to be authenticating with his SP.
The risks of supporting the extension is adequately supporting users whose OP and SP are not the same entity (you don't want to say you'll support the extension and then inadvertently lock out users whose OP is not also their SP).
Keep in mind what you really need to know. If you only want to access the user's private data, but don't really care who the user is that you're interacting with, use just OAuth. No reason for the user to give up his identity via OpenID if you're only downloading his photos to offer a photo printing service, for example, or if you already have a non-OpenID account for this user.
I've been reading about Azure's Access Control Service and claims-based authorization in general for a while now, and for whatever reason, I still don't see the rationale behind moving from role/permission-based authorization to a claims-based model. The models seem similar to me (and they probably are), except that the list of what the client can and can't do comes from a third party and is wrapped up in some sort of token, instead of from some sort of database that the server has to query. What's the advantage of getting a third party (the token issuer) involved?
I fully understand the advantages of outsourcing authentication to a third party. It allows apps to not have to create new users all the time, worry about storing passwords, etc. when they can just push that off to some other service that already has the infrastructure set up. It's essentially the DRY principle for authentication.
However, in my mind, that same logic doesn't work for authorization. Each app has its own resources it has to protect, and therefore its own rules for authorizing users to perform certain actions. The infrastructure seems simple enough that each app could create it on its own (a table mapping users to roles, and possibly another mapping roles to permissions), and even if you wanted to outsource it, it seems that the claims-based model is doing something more complicated than that.
The only partial explanation I've seen comes from Building a Claims-Based Security Model in WCF, and it gives two main advantages to claims-based auth: more flexibility, and someone to "vouch" that the information in a claim is correct. When would you need either of those?
Claims-based authorization seems to be gaining popularity, so I assume there must be some good rationale for it; I just haven't figured out what that is yet. Can someone please provide a concrete example of a situation where claims-based auth works better than role-based, and why it works better in that case?
(EDIT: I missed a third benefit listed in the article: supporting single sign-on/federation. But doesn't authentication deal with that on its own without getting authorization involved?)
I guess the main promise of a benefit from federated security / claims-based system would be one fewer area you have to deal with different systems.
Imagine a site where you have local users authenticating with Windows credentials, a bunch of internet users using username/password, others using certificates, and maybe another group of users with biometric authentication.
In today's system, you have to set up and deal with all different kinds of authentication schemes and their different ways of doing things. That can get pretty messy.
The promise of a federated security solution would be to handle all those chores for you - the STS (security token server) would handle all different kinds of authentication systems for you, and present to you a uniform and trusted set of claims about a caller - no matter from where and on which path he's arriving at your site.
Of course, just examining and reacting to a single set of claims rather than having to understand four, five, ten different and disparate authentication systems looks like a really compelling promise to me!
The purpose of claims based authorization is to allow fine grained access control based on Boolean expressions that evaluate characteristics of the accessing entity and the resource. This reduces or eliminates the need to provision groups. As with federated identity, claims also provide a vehicle for an Identity provider to manage their users wile allowing a resource provider to gate users access to assets.
Note: Claims can be used within a single enterprise and provide the following benefits:
1) Access grants and revocations do not require provisioning or de-provisioning
2) Thus changes are instantaneous
3) Resource owners can define the scope and requirements for access rather than having admins create groups manage group memberships - this moves the access control decisions into the hands of the folks best suited to make such decisions (the data owner)
4) This results in fewer groups being required and fewer member in the groups
5) There can be issues creating a single group to accommodate a large community having access (for
example all full time employees can read a HR policy) - Claims avoids this problem
6) Audit is more informative - the reason a grant or deny took place is clearly visible
7) Claims support dynamic attributes, such as 2-factor authentication, time of day, or network restrictions
There are a lot more reasons, but those ones come to mind. There will shortly be a video at www.cionsystems.com that showcases this (disclaimer - I work there and recorded the video - I still need to post it) Also, for reference, claims aware apps and platforms include SharePoint 2010 on, Windows 2012 (file shares), Azure, many SaaS services (Facebook and Salesforce)
Also, with claims you can blend information from multiple sources (say Facebook and your local AD) etc. - which is increasingly important
Not sure if the rules allow this, but feel free to ping me with your questions or comments. I'll happily edit the post to make any corrections or add pertinent info.
Claims can come from AD, databases tables, SAML, OAuth, algorithms, XACML or any other trusted provider. Harnessing claims requires a bit of kit - with apps and platforms evolving rapidly in this space.
All the Best,
Paul
Claims-based access control also helps build up attribute-based access control and policy-based access control. If you standardize on a set of pre-agreed claims that can be assigned to users based on their other attributes (e.g. a US manager can have claim U_M; a European manager can have claim E_M).
In an attribute-based and policy-based environment, it's possible to achieve fine-grained authorization (also known as fine-grained entitlements) using XACML.
In this case, you can have authorization that depends on who the user is (claims) but also what they want to do (resource information) and under which circumstances (context).
CBAC with XACML will let you express rules like:
managers can edit notes they created themselves or notes that their
direct reports created.
Role based security is a limited security model
Authorization is:
Based on role membership only
Claims based security is much more flexible and expressive
Authorisation can be:
Based on role membership
Based on Age
Based on Geographic Location
Based on an account balance
Based on a size
Based on pre-defined securtiy levels
Based on any combination of the above