The OAuth 2.0 protocol is one of the most widely deployed authorization/single sign-on (SSO) protocols
and also serves as the foundation for the new SSO standard OpenID Connect. Despite the popularity
of OAuth, so far analysis efforts were mostly targeted at finding bugs in specific implementations and
were based on formal models which abstract from many web features or did not provide a formal treatment
In this paper, we carry out the first extensive formal analysis of the OAuth 2.0 standard in an expressive
web model. Our analysis aims at establishing strong authorization, authentication, and session
integrity guarantees, for which we provide formal definitions. In our formal analysis, all four OAuth
grant types (authorization code grant, implicit grant, resource owner password credentials grant, and
the client credentials grant) are covered. They may even run simultaneously in the same and different
relying parties and identity providers, where malicious relying parties, identity providers, and browsers
are considered as well. Our modeling and analysis of the OAuth 2.0 standard assumes that security
recommendations and best practices are followed in order to avoid obvious and known attacks.
When proving the security of OAuth in our model, we discovered four attacks which break the security
of OAuth. The vulnerabilities can be exploited in practice and are present also in OpenID Connect.
We propose fixes for the identified vulnerabilities, and then, for the first time, actually prove the
security of OAuth in an expressive web model. In particular, we show that the fixed version of OAuth
(with security recommendations and best practices in place) provides the authorization, authentication,
and session integrity properties we specify.
Slides from two day course on Vanadium https://vanadium.github.io/
Production systems at Google consist of a constellation of microservices1 that collectively issue O(1010) Remote Procedure Calls (RPCs) per second. When a Google engineer schedules a production workload2, any RPCs issued or received by that workload are protected with ALTS by default. This automatic, zero-configuration protection is provided by Google’s Application Layer Transport Security (ALTS). In addition to the automatic protections conferred on RPC’s, ALTS also facilitates easy service replication, load balancing, and rescheduling across production machines. This paper describes ALTS and explores its deployment over Google’s production infrastructure.
Abstract. Access control is central to security in computer systems. Over the
years, there have been many efforts to explain and to improve access control,
sometimes with logical ideas and tools. This paper is a partial survey and discussion
of the role of logic in access control. It considers logical foundations
for access control and their applications, in particular in languages for security
policies. It focuses on some specific logics and their properties. It is intended
as a written counterpart to a tutorial given at the 2009 International School on
Foundations of Security Analysis and Design.
Access control is central to security in computer systems.
Over the years, there have been many efforts to explain and
to improve access control, sometimes with logical ideas and
tools. This paper is a partial survey and discussion of the
role of logic in access control. It considers logical foundations
for access control and their applications, in particular
in languages for programming security policies.
Today, we’re putting our core web services behind the protections provided by U2F and Google’s account takeover and anomaly detection systems. Not only will this provide phishing resistance through the authentication proxy, but also authorization through IAM roles assigned to the user’s Google account.
- Google account
- U2F Yubikey enrolled and enforced for the users/groups that will be accessing the application.
- An hour or so.
- A global cloud that has been operating at billions of rps for decades. (Beyond the scope of this article.)
(notes from Next ’17)
Types of identities
|Google Account||Service Account||G Suite Domain||Google Group|
|Represents||Employee or User||Application Component||All members of the specified domain||All members of the group|
|Log in to Console?||Yes||No||No||No|
|Notes||An instance can run as a service account.|