Double-blind Identity

Note: Cross-posted from the Oracle Fusion Blog.

On November 13 and 14, the Government of British Columbia, Canada, launched the first in a series of public consultations on identity and digital services. For several years now, BC has been working on a new identity services project that would enable citizens to securely access government services online. For BC, there is clear motivation: reducing identity management and fraud costs in everything from drivers licenses to health insurance. BC's hope is that this can play a role in helping provide better services down the road as well as improving the overall privacy of residents.


For background to the challenges and motivations for BC, check out former BC CIO Dave Nikolejsin's talk on the importance of identity management in 2012 and the principles behind BC's identity project:

Incidentally my favourite quote from this video is: "Government will never be downstream from your Facebook account".

This first public consultation was focused as technical level-set meeting including standards community members from companies like Microsoft and Oracle and other vendors, as well as some members US Govt's NSTIC program, New Zealand Gov't, and British Columbia including its privacy commissioner, Elizabeth Denham. Most importantly, the meeting included several members of the general BC public picked at random from over 15,000 applicants. The day was spent educating and putting participants on a more equal footing on the basics of identity theory as well the challenges and objectives BC has for this program.

As part of this level-set, Collin Wallis, Identity Architect for the New Zealand Gov't, gave a great talk on how NZ and BC are similar in size and have many of the same overall cultural values and privacy concerns. He spoke about NZ's current "RealMe" deployments and their immediate focus on the "authentication". A similar presentation is available here.

The BC Gov't showed an overall architecture based on issuing new driver's licenses and Government Services Cards with near field chips (NFCs) supplied by SecureKey. The architecture depends mainly on OAuth2 authorization and SAML federation techniques that provide a "directed" identifier approach creating an infrastructure that has privacy qualities that could be said to be "double-blind".

You may recall that the term "double-blind" comes from medical research where both the tester and subject are blinded.  In the case of identity, the term implies the authenticator and relying party are blinded in a way that ensures privacy for the subject (the citizen).  The authenticator is not able to observe what personal information is shared or how the identifier is used assuring the citizen of freedom of use without monitoring. The relying party receives a directed identifier for the citizen unique to the relying party's use (see Kim Cameron's Law of Identity #4). What this stuff means is that two relying parties cannot share information directly based on a common identifier (as would happen if one used an omni-directional identifier like a SSN/SIN or Driver's License number). The same individual authenticating to two different parties appears to have separate identities. Hence the architecture could be said to be a double-blind system with strong privacy enabling qualities in its core design.

If successful, NZ and BC citizens may soon use their New Zealand RealMe or BC Government Services Id as a common authenticator to login and/or obtain services, while at the same time, avoid the privacy problems that occur when using a common identity such as offered by social networks, using personal email addresses. Their biggest challenge: BC and NZ need to avoid the fears of other national identity programs such as the US's "REAL ID" or the UK's "National ID" programs by building public confidence in its privacy-centred architecture.

For me personally, the most inspirational aspect of the consultation process was the leadership that Minister Andrew Wilkinson and his CTO, Ian Bailey, showed by adopting an "unconference" format that those of us in the IAM industry have come to know well at our regular meeting Internet Identity Workshop meetings. Following the first day's level-set session, an unconference session was led by Kaliya Hamlin (aka IdentityWoman) as well as Aron and Mike of IdentityNorth on the second day. This format was so successful that the group acknowledged highlights of the day were the members of the general public who chose not only to participate in deep theoretical discussion, but lead 3 of the most insightful sessions of the day!

To be clear, double-blind identity is not necessarily that new--we may have just put a term to it. After-all, there have been many systems with pseudononymous authentication. However, as technologists, we've been too accustomed to centralized architectures where both authentication and personal information in the form of claims come from a common provider (an Identity Provider). In these traditional enterprise architectures privacy has taken a back seat since employees don't often need to expect privacy in regards to performing their jobs. In contrast, these two governments are showing that privacy-enabled identity systems require separation of personal information from authentication services. I wonder what this means for cloud services architectures of the future and whether the current all-knowing social networks can survive the privacy problems they are running into by amassing so much information. It certainly suggests that the social network big data approach where all personal information is in one place is not the right way to go if governments really care about privacy.

Disclosure:  I am a resident of British Columbia. While my employer is a supplier to the government of British Columbia, I am not currently directly involved in this or any other projects with BC. My participation and comments are based as both resident and a member of the identity standards community. The views expressed are my own and do not necessarily reflect those of my employer.

Standards Corner: OAuth WG Client Registration Problem

Update: Cross-Posted on the Oracle Fusion Middleware blog.

This afternoon, the OAuth Working Group will meet at IETF88 in Vancouver to discuss some important topics important to the maturation of OAuth. One of them is the OAuth client registration problem.

OAuth (RFC6749) was initially developed with a simple deployment model where there is only monopoly or singleton cloud instance of a web API (e.g. there is one Facebook, one Google, on LinkedIn, and so on). When the API publisher and API deployer are the same monolithic entity, it easy for developers to contact the provider and register their app to obtain a client_id and credential.

But what happens when the API is for an open source project where there may be 1000s of deployed copies of the API (e.g. such as wordpress).  In these cases, the authors of the API are not the people running the API. In these scenarios, how does the developer obtain a client_id?

An example of an "open deployed" API is OpenID Connect. Connect defines an OAuth protected resource API that can provide personal information about an authenticated user -- in effect creating a potentially common API for potential identity providers like Facebook, Google, Microsoft, Salesforce, or Oracle.  In Oracle's case, Fusion applications will soon have RESTful APIs that are deployed in many different ways in many different environments. How will developers write apps that can work against an openly deployed API with whom the developer can have no prior relationship?

At present, the OAuth Working Group has two proposals two consider:

Dynamic Registration

Dynamic Registration was originally developed for OpenID Connect and UMA. It defines a RESTful API in which a prospective client application with no client_id creates a new client registration record with a service provider and is issued a client_id and credential along with a registration token that can be used to update registration over time.

As proof of success, the OIDC community has done substantial implementation of this spec and feels committed to its use.  Why not approve?

Well, the answer is that some of us had some concerns, namely:

1. Recognizing instances of software - dynamic registration treats all clients as unique. It has no defined way to recognize that multiple copies of the same client are being registered other then assuming if the registration parameters are similar it might be the same client.
2. Versioning and Policy Approval of open APIs and clients - many service providers have to worry about change management. They expect to have approval cycles that approve versions of server and client software for use in their environment.  In some cases approval might be wide open, but in many cases, approval might be down to the specific class of software and version.
3. Registration updates - when does a client actually need to update its registration?  Shouldn't it be never?  Is there some characteristic of deployed code that would cause it to change?
4. Options lead to complexity - because each client is treated as unique, it becomes unclear how the clients and servers will agree on what credentials forms are acceptable and what OAuth features are allowed and disallowed.  Yet the reality is, developers will write their application to work in a limited number of ways. They can't implement all the permutations and combinations that potential service providers might choose.
5. Stateful registration - if the primary motivation for registration is to obtain a client_id and credential, why can't this be done in a stateless fashion using assertions?
6. Denial of service - With so much stateful registration and the need for multiple tokens to be issued, will this not lead to a denial of service attack / risk of resource depletion?  At the very least, because of the information gathered, it would difficult for service providers to clean up "failed" registrations and determine active from inactive or false clients.
7. There has yet to be much wide-scale "production" use of dynamic registration other than in small closed communities.

Client Association

A second proposal, Client Association, has been put forward by Tony Nadalin of Microsoft and myself. We took at look at existing use patterns to come up with a new proposal. At the Berlin meeting, we considered how WS-STS systems work.  More recently, I took a review of how mobile messaging clients work. I looked at how Apple, Google, and Microsoft each handle registration with APNS, GCM, and WNS, and a similar pattern emerges.  This pattern is to use an existing credential (mutual TLS auth), or client bearer assertion and swap for a device specific bearer assertion.

In the client association proposal, the developer's registration with the API publisher is handled by having the developer register with an API publisher (as opposed to the party deploying the API) and obtaining a software "statement". Or, if there is no "publisher" that can sign a statement, the developer may include their own self-asserted software statement.

A software statement is a special type of assertion that serves to lock application registration profile information in a signed assertion. The statement is included with the client application and can then be used by the client to swap for an instance specific client assertion as defined by section 4.2 of the OAuth Assertion draft and profiled in the Client Association draft. The software statement provides a way for service provider to recognize and configure policy to approve classes of software clients, and simplifies the actual registration to a simple assertion swap. Because the registration is an assertion swap, registration is no longer "stateful" - meaning the service provider does not need to store any information to support the client (unless it wants to).

Has this been implemented yet? Not directly. We've only delivered draft 00 as an alternate way of solving the problem using well-known patterns whose security characteristics and scale characteristics are well understood.

Dynamic Take II

At roughly the same time that Client Association and Software Statement were published, the authors of Dynamic Registration published a "split" version of the Dynamic Registration (draft-richer-oauth-dyn-reg-core and draft-richer-oauth-dyn-reg-management). While some of the concerns above are addressed, some differences remain. Registration is now a simple POST request. However it defines a new method for issuing client tokens where as Client Association uses RFC6749's existing extension point. The concern here is whether future client access token formats would be addressed properly.  Finally, Dyn-reg-core does not yet support software statements.

Conclusion

The WG has some interesting discussion to bring this back to a single set of specifications. Dynamic Registration has significant implementation, but Client Association could be a much improved way to simplify implementation of the overall OpenID Connect specification and improve adoption. In fairness, the existing editors have already come a long way. Yet there are those with significant investment in the current draft. There are many that have expressed they don't care. They just want a standard. There is lots of pressure on the working group to reach consensus quickly.

And that folks is how the sausage is made.

Note:  John Bradley and Justin Richer recently published draft-bradley-stateless-oauth-client-00 which on first look are getting closer. Some of the details seem less well defined, but the same could be said of client-assoc and software-statement. I hope we can merge these specs this week.

New Draft for Enabling OAuth2 To Be Used for Authentication

In my last blog post, I discussed the issue of OAuth2 and authentication:  Simple Authentication for OAuth 2? What is the Right Approach? As promised, I submitted a draft to the IETF for discussion in Berlin at the beginning of the month. While the working group didn't get a lot of time in the meeting to talk about the authentication issue (it wasn't formally on the charter), the submission did receive quite a bit of discussion in the hallways and on the IETF OAuth WG mailing list -- some of which I have already addressed in my last blog post.

Since the Berlin meeting, I have reviewed the feedback and have submitted an update. Draft 01 is now aligned to be compatible with OpenID Connect. In other words:

• If you are a web  developer, and the only problem you want to solve today is "how can I use OAuth to authenticate my users?", the new User Authentication and Consent for Clients draft is intended to solve just that problem. 
• But, if you decide you want to add an attribute provider (user profile) services to your requirements, you can upgrade to the OpenID Connect drafts as an extension to authentication without impacting existing code.

The new draft also allows clients to request a minimum Level of Assurance (per NIST-800-63 or ISO 29115) for the authentication -- a useful feature if the clients would like the service provider to do a higher assurance authentication (such as a multi-factor or biometric) than it might otherwise normally perform.

My thanks to Tony Nadalin and Mike Jones of Microsoft for their contributions to this draft.

Simple Authentication for OAuth 2? What is the Right Approach?

Over a year ago, several people, including myself, raised concerns about using OAuth (RFC6749) for authentication. By this I mean, that application developers are using OAuth enabled service providers as a way to authenticate their users (using Google, Facebook, LinkedIn, Twitter, or another major provider). They do this because they want to eliminate friction by forcing customers to create yet-another-user-id-and-password. John Bradley blogged about the problem, as did Vittorio Bertocci. Vittorio pointed out that authentication using OAuth is possible – it is just that authentication isn't formalized; authentication happens as a side-effect of authorizing a client to access a resource.

I agree with Vittorio, to fix this a simple specification is needed where by a service provider's authorization server shares with the client application (the one that wants to authenticate users), the user login information it knows about the user such as:

• Which user-id was authenticated?
• When did they login?
• How long is the login assertion good for?
• A possible (preferably directed) URI for User profile information?
• And, potentially to what assertion level were they authenticated? 

Many, including myself, suggested that the solution to the problem is to use OpenID Connect (OIDC).  OIDC solves the authentication standardization problem and further, it specifies a way to gain access to user profile information. In a sense, it turns an OAuth2 Service Provider into what we used to call an Identity Provider or IDP in many federation systems.

Despite these strong recommendations, I continue to see implementations and customer requests that require doing exactly what we warned was not standardized and not a good practice. Part of the complaint is that service providers have been slow to adopt except for a notable exceptions (namely Google). I also heard from last weeks CIS Nape conference that SFDC is planning to include OIDC in its platform.

I have asked many of the OIDF membership about this, and they claim there is a minimum profile. Yet, the "minimum" profile exists for the clients, not for the service providers. In a conversation only yesterday with Brian Campbell of PingIdentity (some tweets removed for clarity), we quickly got to the crux of the issue:

@leastprivilege @independentid @paulmadsen @vibronet there already is. You just have to find it in the mountain of specs.
— Brian Campbell (@__b_c) July 17, 2013

@leastprivilege @independentid @paulmadsen @vibronet response_type=id_token and scope=openid+whatever
— Brian Campbell (@__b_c) July 17, 2013

@__b_c @leastprivilege @paulmadsen @vibronet right but as can't implement just that flow.
— Phil Hunt (@independentid) July 17, 2013

@independentid @leastprivilege @paulmadsen @vibronet they could if ignore MTI, which will happen I'm sure
— Brian Campbell (@__b_c) July 17, 2013

Brian went on to point out some other important concerns, such as will another spec cause more confusion than it prevents. He is right.

So, while it is possible for OIDC to do authentication only, it wasn't intended for this purpose. Further, OIDC requires that the scope parameter which is intended to refer to the resource being requested, is compounded with an additional parameter "openid".

OIDC has many features, including discovery, that are incredibly useful.  Loosely speaking it turns OAuth2 Service Providers into the older federation Identity Provider model. It imagines an ecosystem of OIDC providers where profile information can be obtained in a standard way. Yet, many client developers aren't interested in user profile attributes – they just want to eliminate the need for users to create yet another user-id and password. They just want the login session information and the ability to force re-authentication.

From the service provider's (e.g. the social networks) perspective, there are also concerns. They know that client application developers are using OAuth2 to leverage their authentication services. Yet, their business priorities aren't such that the service providers want to consider becoming a standard compliant provider of user profile information. What service providers would like is a way to support standardized authentication, without standardizing their own RESTful profile APIs or adding another API. Implementing the OIDC Profile API may be in their future, but they aren't ready to commit today.

One of the problems we have in the standards industry is we tend to want mark the number of "implementations" as a sign of success. We tend to ignore those who are not implementing or are not putting implementations into production. These silent participants often do not voice their concerns.

It's with these concerns, that I am writing a proposal to respond to the authenticate only need. The plan is to make it short and easy to implement. I plan to submit it when the next IETF submission window opens on July 29. Yet I hesitate to submit it. Should it go to the IETF?  After, all, that is where the security concern lies. Or is it something the OIDC designers should look at?  I'd like to open some discussion on this. What should be done about supporting authentication directly within OAuth2 as described above? Where should that work be take place?

If anyone is interested, please make a comment or send me an email. I'd like to get your input, concerns, and support.

Why You Should Care About Privacy

On April 4, at 10am Pacific, Oracle Identity Management (@OracleIDM) will be hosting a twitter conversation on privacy (#PrivQA). I am pleased to confirm that the Ontario Commissioner of Information & Privacy, Dr. Cavoukian will be joining the conversation. In particular, I would like to encourage privacy and security industry folks to participate. For more information, see our recent newsletter Q&A with links to her whitepaper on privacy by design (PbD).

Privacy is an issue that has been of concern to myself and many other industry professionals. Most of us continue to be amazed that for the most part, both users and the application developer community simply do not care. When the subject arises, eyes immediately shut with yawns soon to follow.

Yet, every day, more and more problems emerge in the industry that are leading to monetary and even physical harm. For example, financial fraud appears to be exploding fuelled by easy access to personal information available on social services. Fraudsters combine social demographic information to leverage weak classic communications media like fax and telephone to convince financial institutions to transfer funds (see Canadian Government Advisory on Social Fraud). In another case, access to private information in Google, apparently enabled hackers to compromise Mat Honan's Apple accounts, even remotely wiping out his laptop, iPad, and iPhone (Wired Article). Here, where I live in BC, there is the sad story of Amanda Todd, who was bullied to the point, she committed suicide. Was this a lack of privacy? Was there a lack of appropriate anonymity? Was this poor system design? We are only just beginning to understand how far reaching privacy issues can be.

These cases also show there are some interesting relationships between anonymity, privacy, and security that need further exploration. Do I need to be anonymous? I live an honest life, why do I need to keep my personal information private? Why should I care about anonymity? The system is secure right? Nobody asks who is the security intended for. What motivates the service providers? What damages do they face in the event of real losses? We are now discovering that while we may have the best of intentions, the fraudsters out there do not. Boring as the subject of privacy may seem, we should all be worried. We should all care.

Dr. Cavoukian's efforts to get our industry to start thinking about Privacy-by-Design are to be applauded. I'm not sure where this will go, but I'm glad this conversation has started. Remember to join in the twitter conversation on April 4 at 10AM (Twitter hashtag #PrivQA).

Originally posted on: Oracle IDM Blog.

Standards Corner: Tokens. Can You Bear It?

This week's post is all about tokens. What are the different types of tokens that may be used in RESTful services? How are they the same/different from browser cookies? What are access tokens, artifacts, bearer tokens, and MAC tokens?

If I asked you what are tokens used for, many of you would answer authentication. But there is a bit more to it than that. First, I'd like to point you to a post I wrote on my personal blog called "3 Parts to Authentication"

In this post, authentication is described as a process broken down into 3 parts:
1. Registration
2. Credential Presentation
3. Message Authentication

What's important here is that many often confuse the process of credential presentation with message authentication. Credential presentation is the process where a user or an HTTP client application demonstrate (with one or more factors), that the user or HTTP client application in question is the same one that was previously registered. Having successfully completed the credential presentation process, the authenticator issues a cookie or token which can be used for a period of time, as a means of message authentication -- creating a single-sign-on session.

Today's post focuses on step 3, using cookies or tokens to access web resources. In browsers, cookies are added to requests in order to allow web sites to perform message authentication -- in effect creating the effect of single-sign-on. HTTP client applications use tokens in much the same way. They pass tokens, given to them by an authorization server, in the HTTP Authorization header of requests to achieve the same thing cookies do for browsers. In the case of tokens issued by an OAuth2 Authorization server (as with Kerberos and others), we call these tokens "access tokens" because they are used to access web resources.

Broadly speaking, there are 2 categories of tokens web sites may accept: bearer tokens and proof tokens. Bearer tokens work very much like browser cookies. They can be a simple unique identifier (aka artifact), or they can be encoded strings that have meaning to the web sites they are intended for. However to the client, these cookies are just random (opaque) text strings that need to be passed to the web site in order to access a resource (message authentication). Because the client doesn't have to do anything but merely attach a bearer token to its request, bearer tokens are very simple for client developers to use. For more details on bearer tokens, check out RFC 6750 The OAuth 2.0 Authorization Framework: Bearer Token Usage.

While bearer tokens are incredibly simple and easy to use, there is a downside. Any client that obtains a copy of the bearer token may use it. Simple possession is enough to access the web resource (hence the term bearer). So, a critical limitation of bearer tokens is they SHOULD NOT be used over plain HTTP since they can be sniffed and copied. Web sites, accepting tokens should consider whether there is a possibility that access tokens could be sniffed or otherwise shared and does that impose a risk. Because of this, the IETF OAuth Working Group is nowworking on requirements for Holder-of-Key tokens (aka proof tokens).This document describes in detail the kinds of problems that could be solved and attempts to get to a set of use case requirements for a final token specification.

Proof tokens require an HTTP client to perform some kind of calculation that shows that only it could have used the token (such as with a private key or other shared secret). In a HoK token, a client could be required to generate a request signature, and even add a counter in order to prevent play-back attacks in addition to simple proof of a client's right to use a token. An example of this is the MAC token draft. The OAuth2 Working Group is debating whether this specification should move forward or whether a simpler specification based on JSON Tokens (JWT) should be developed.

So, in many ways, tokens build on the experience industry has had for many years with browsers and single-sign-on cookies. Tokens wielded by HTTP clients accessing RESTful web resources achieve the same feature we've taken for granted with browsers. Bearer tokens are easy for most clients to use, but require secure connections when used to prevent sniffing. Proof/HoK tokens can be used to where web resources are either unprotected, or further proof of the right to use a token is needed.

Cross-posted from OracleIDM.

3 Parts to Authentication

At the IETF85 meeting in Atlanta, I ran into Phillip Hallam-Baker after a meeting on HTTP Authentication (you may recall, Phillip is one of the editors of RFC2617 - Basic and Digest Access Authentication). We were talking about how the term "authentication" is very poorly defined and means different things to different people and different service components.

Phil pointed me to a WG draft he put together as input to the HTTP Working Group - "HTTP Authentication Considerations". In section 2, he points out that authentication has several parts:

• registration, 
• credential presentation, and 
• message (aka session) authentication.

The term 'authentication' tends to cause confusion due to the fact that there are actually three separate activities that it can refer to. When Alice establishes an account at a Web site, the site may verify her email address is correct. When Alice presents her username and password, the site verifies the data and if correct issues a HTTP cookie. When Alice re-visits the same Web site to make further requests, the cookie is verified each time. Each of these verifications is a form of authentication but they are totally different in character and only the last of these is a form of authentication that is directly related to HTTP.

Attempts have been made to distinguish between these as 'initial authentication' and 're-authentication' but this also creates confusion as some people consider the first contact with the user as the 'initial' authentication and others consider that to be the start of a Web session.

I have seen a lot of confusion about the purpose of access tokens in OAuth. Some feel that there should be strong authentication with every HTTP requests. But when you look at it how Phil lays it out, it's clear that the job of message authentication is simply to maintain session state across multiple HTTP requests. It has very different requirements from credential presentation.

Phil also has some interesting commentary on some of the problems with passwords like promiscuity, recovery, phishing, and lock-in issues. Many of us have for some time been on a rant about killing the password - but Phil talks plainly about what 'passwords get right'.

This is a great read.

OAuth2: Is OAuth the End of SAML? Or a New Opportunity?

I mentioned in my year in review post that rather then spell the end of SAML, OAuth2 might in fact greatly expand SAML's adoption. Why is that?

The OAuth2 Working Group is nearing completion on the OAuth2 SAML Bearer draft which defines how SAML Bearer assertions can be used with OAuth2 essentially replacing less secure user-id and passwords with more secure federated assertions.

Before I describe how this works, here is some quick terminology:

• Resource Service - A service offering access to resources, some or all of which may be "owned" or "controlled by" users known as "Resource Owners".
• Resource Owner - An end user, who is authorizing delegated scoped access by a client to resources offered by a Resource Service
• Client - An application (e.g. mobile app, or web site) that wants to access resources on a Resource Service on behalf of a Resource Owner.
• Authorization Service - A service authorized to issue access tokens to Clients on behalf of a resource server.

While the resource service and the authorization service may be authenticated by means of TLS domain name certificate, both the client application and the end-user often need to be authenticated. In "classic" OAuth, you can use simple user-id's and passwords for both. The SAML2 Bearer draft describes how federated SAML assertions can be used instead.

A typical scenario goes much like this.

OAuth2 with SAML

1. Alice (resource owner) accesses a corporate travel booking application. 
2. In order to log into the corporate travel application, Alice is redirected to her employer's Identity Provider to obtain a SAML Authentication Assertion. 
3. Upon logging in to the Corporate Travel Application, Alice wishes to update her seat preferences with her selected airline. In order to do this, the corporate travel application goes to the authorization server for the airline. The travel application provides two SAML authentication assertions: 1) An assertion representing the identity of the client application, and 2) an assertion representing Alice. The scope requested is "readProfile seat". 
4. Upon verifying the SAML assertions and delegated authority requested, the authorization server issues an access token enabling the corporate travel application to act on behalf of Alice.
5. Upon receiving the access token, the corporate travel app is then able to access the frequent flyer account web resource by passing the token in the header of the HTTP Request. The Access token, acts as a session token that encapsulates the fact that the travel app is acting for Alice with scope read & seat update. 

This SAML Bearer flow is actually very similar to the classic OAuth 3-leg flow. However instead of redirecting the user's browser to the authorization server in the first leg, the corporate travel app works with the user's IDP to obtain a delegation (or simple authentication) assertion direct from the IDP. Instead of swapping a code in the second leg, the client app now swaps a SAML Bearer assertion for the user.

OAuth2's ability to leverage different authentication systems makes it possible for SAML to enhance OAuth2 security going even further to eliminate the propagation of dreaded user-ids and passwords in much the same way SAML did for classic federate web sign-on. Rather than making SAML redundant, OAuth2 has in fact increased SAML's utility.

Note: this post cross-posted from the OracleIDM blog.

OAuth2: How does OAuth2 Make Crypto Easier for Developers

Note: cross-posted on OracleIDM blog.

On my last blog post on Oracle IDM, Marc asks some very good questions that deserve a longer response:

Phil,

Here's where I get confused about OAuth2. I keep hearing you don't need crypto (which is often where developers get so tripped up on other federation protocols) but how do you securely have a self contained token without crypto? You mention signing a token, but isn't that crypto? If you are relying solely on transport security does that mean all connections need to be HTTPS mutual authentication to be viable?

Thanks
Marc

Let me break this up into a couple of paraphrased pieces:

1. If you do not use crypto, how do you securely have a self-contained token without crypto (aka bearer token)?

In OAuth1, the algorithm, usage and signing instructions were narrowly defined (probably limiting the life of the spec). OAuth1, assumed all communication would be insecure and therefore the access token itself needed to be secure. This required each client developer to implement the specifications MAC token in order to access services.

In contrast, OAuth2 the assumptions are reversed. Communication are secure, so tokens do not need to be self-securing (as MAC tokens were in OAuth1). OAuth2 opens the door to using simple bearer tokens (RFC 6750) to access services. OAuth2 assumes that because the issuing process is secured by TLS, the mere possession of a valid token is sufficient to authenticate or rather maintain the session relationship with the client.

With that said, there are still many scenarios where stronger ongoing authentication of the client is important to improve security. For a larger discussion on this, check out the current OAuth2 WG Security draft which discusses these issues.

2. Does this mean all connections must be HTTPS mutual authentication to be viable?

Mutual:
TLS Mutual authentication is useful, but is not required. OAuth2 allows the client application to be authenticated through other means such as client secret, a JWT, or SAML assertion. One of the problems with TLS mutual authentication is when TLS terminates before the server (e.g. in a load balancer), the server may not be able to access the client's authentication with the load balancer.

All:
Let me first qualify that not all communication needs to be secured in all cases. Let's look at the two main endpoints that are being communicated with. The Authorization Server (aka Token Server), does require that at least server-authenticated TLS be enabled for all communication. In the case of a Resource Server, server-authenticated TLS is not required but SHOULD be used when using tokens without crypto (aka bearer tokens).

Thanks for the questions. Please keep them coming!

Is OAuth2 Ready for Use?

In what seems to be becoming a regular thing, I have another blog post on the Oracle IDM blog, "Standards Corner: A Look at OAuth2", where I answer some tough questions:

• What is the difference between OAuth1 and OAuth2?
• Is OAuth2 mature enough to use?
• Should customers deploy OAuth1?
• What's happening with OAuth2?