0

Modern authentication solutions with OAuth 2 0, OpenId Connect and AngularJS – Manfred Steyer


Welcome, everybody. Welcome to my talk about
[? small town ?] authentication solutions. I am Manfred Steyer. I work and live
in Austria, and I am a consultant
as well as trainer in the area of web and
service development. I also write from time to time. My last book was about
AngularJS at O’Reilly. So what are the
contents of this talk? I want to give a motivation
to you about small town authentication
scenarios, and then I want to give an
overview of OAuth 2.0, as well as of OpenID Connect. And then I will show
you a demonstration I have prepared for that. So let’s start with
the motivation. In this world, every user has to
maintain several user accounts. Nearly every application,
every business application, and every web application
we use demands on managing an own user account. And as you know, that
gives us a very hard time. In addition to that,
there are more and more applications that want to access
some services, some back end services, on behalf of us. And when it comes
to applications, we not fully trust when
it comes to applications that we have downloaded
from some application store, or from the internet. We don’t feel comfortable
by typing in our password into those applications. And this is exactly
where OAuth 2.0 comes in. OAuth is a solution that has
been developed by Twitter and Ma.gnolia and that is a
standard for the delegation of restricted rights. That means, using OAuth,
you can give an application some restricted
rights– for instance, the rights to do some use
cases on behalf of you at Twitter, at Facebook,
or within some business application. And OAuth is quite popular. It has been adopted
by huge companies like Google, Facebook,
Flickr, Microsoft, and so on. When you look at OAuth,
there are several roles. For instance, there
is the client, the client that wants to
access some server that is called resource-server
on behalf of the user. And, of course,
there is the user that is called resource owner
when it comes to OAuth 2.0. Neither the client nor
the resource-server have access to
the user accounts. There are central user
accounts, and only an instance called the
authorization server has access to these user accounts. When you look at OAuth from
a high level perspective, everything begins with the
client redirecting the user to the authorization server. And as part of this
redirection, the client transmits a variable
called scope. This scope denotes the
rights the client wants to have from the user,
and when the user arrives at the authorization
server, the user has to log in. And then the authorization
server asks the user, do you really want to
delegate these entered rights to this entered client? And then the user says
no, and we’re done. Thank you for this. No, no. Wait a minute. Or they use user
says, yes, of course. This client can have
this or that rights, and then the user is
redirected back to the client. And as part of this
redirection, the client gets an access token. And the client can
use this access token to access the resource-server
on behalf of this user. You can think about the access
token like about some visa, or like about some passport
or driver’s license. This token gives the
client the permission to act on behalf of the user. And this brings some
advantages into play. For instance, with
this scenario you can use central user accounts. You can have one and only one
user accounts for one user, and this user can use those user
accounts for several clients as well as for several
resource servers. And in addition
to that, you only have to put in your password at
the side of the authorization server. You don’t have to
put in your password at the client, which is
especially useful when it comes to a situation
where you don’t fully trust your client. The details regarding
the communication between the client and
the authorization server depends on the flow you choose. OAuth 2.0 defines several
flows for several use cases. For instance, there is a flow
called authorization code grant. This flow has been assigned for
server-side web applications. And in addition to that,
there is also another flow. It is called implicit
grant, and this flow has been designed for
applications like single page applications. In my demonstration, I will
focus on this implicit grant. So let’s talk about
authentication scenarios with OAuth 2.0. Until now, we’ve just seen how
to use OAuth 2.0 to delegate some rights, but OAuth 2.0 can
also be used for authentication for logging in the user. And when it comes to
logging in the user, everything is about
to help the client to find out who the user is. And for this, the
client just requests a token that gives
the permission to read the user profile. And when the client
got this token, the client can use this token
to access the resource-server and to read the profile
of the current user. So that is all the client has to
do to find out who the user is. The issue with that is
that the user profile isn’t defined by OAuth 2.0. OAuth 2.0 just defines
the communication between the client and
the authorization server. OAuth 2.0 doesn’t
define anything about the resource server
or about user profiles, and that is exactly where
OpenID Connect comes in. OpenID Connect is an
extension of OAuth 2.0, and it defines how to use
OAuth 2.0 for authentication scenarios. It defines how to
query a user profile, and it also defines
that the client gets a so-called identity token. An identity token
is a JSON web token. Just think of it like
of a JSON document that consists of some
information about the user– username, email address,
company, and so on. And this token can be
signed by the issuer that is the authorization server. And in addition to
that, OpenID Connect shuts down some
security holes that can arise when you are using
OAuth 2.0 for authentication scenarios. When you are doing
OAuth 2.0 or when you are doing OpenID Connect,
you are just doing OAuth 2.0. And as a result of this, you
don’t only get an access token. You get an identity token
that helps the client to find out who the user is. So the identity token is
primarily for the client, and the access token is the
token we got via OAuth 2.0, and this token is, as mentioned
before, for the service. With this token, the client
can access the service on behalf of the user. So let’s look at a demonstration
I’ve prepared [INAUDIBLE]. This demonstration is about
a simple Angular application that provides us to
buy some vouchers. And when I click on Voucher,
I can buy a voucher. And for buying a voucher,
I have to be logged in. Therefore, I click on Login. Then I’m redirected to
an authorization server. I am already logged in in
this authentication server. This authentication server
bases on IdentityServer3, which is a very nice open
source project for building your own authorization server
or authentication server. And this server asks
if I want to delegate some rights to the client. The client wants to have the
right to read my user ID. It wants to have the right
to read my user profile– things like my first name,
my last name, and so on. And this client wants to have
the rights to buy vouchers in my name. And then I say, yes, I want
to delegate all these rights to my client, and then the
client gets two tokens. It gets the identity token,
and this identity token helps the client to
find out who I am. And it gets an access token,
and it can use this access token to buy a voucher in my name. So let’s try that. Let’s buy a voucher. We see that I can access some
back end surveys, some resource server. And when I present my token
to this resource server, then I get a voucher. That’s great. Let’s just do the same example
by the usage of Fiddler. Fiddler is a very
small HTTP proxy that helps me to capture all
the HTTP traffic I’m causing. So let’s go to my
demo application. Let’s go to voucher. Let’s log out, and
let’s just log in. So here I have to provide my
password and my user name, and then I say that
the current application gets all those rights. Yes, I allow a purchase, and
then I will buy some voucher. So let’s have a look at the
HTTP traffic I’ve caused. Here we see the redirection
to the identity server, and we look at the
protocol information. We see that I’m transmitting
a lot of parameters, a lot of parameters using the
query string to the identity server, and here is a
better view for that. When we look at this, we see
that my client is transmitting things like the ID
of the current client to the authorization server. The client is transmitting
its own address to the authorization server. The address– we are redirected
after we’ve logged in, and we see here that there
is some scope transmitted. And as mentioned
before, this scope denotes which rights the client
wants to have from the user. |n this case, the client
wants to have to right OpenID. That means it wants to
have the rights to read the ID of the current user. It wants to have
the right profile. That means it wants to
read the user profile. It also wants to read the email
address of the current user. And of course, the client
wants to have the right to buy a voucher in
the name of the user. So that is the request. After I’ve logged in and after
I granted all these rights to the client, I was redirected
back to my application. So we should see some
redirection somewhere here. Here we have it, an HTTP
message with the code 302. And this redirection points
me back to my application. So let’s take out this
header, this location header, as you see here. This redirection points me back. That is the wrong one. Sorry for that. Where is the right one? 302. Found, and there should
be some location header. This is the right one. That looks quite better. As we see here, I’m redirected
back to my demonstration application. And as part of
this, my application gets some token, some
very small tokens. There is an identity token,
and somewhere below there is this access token. So let’s look for access. Here is the access token. And both tokens are
JSON web tokens. And perhaps you are wondering,
because this doesn’t exactly look like JSON,
and you are right. That doesn’t exactly
look like JSON. But you have to know that
a JSON web token is just some string that consists
of several parts, and those parts are
separated by a point. So here we have the
first part, and here we have the second part,
and the third part. The first part is about the
header of the JSON web token. It is just a JSON document
that is encoded with base 64. The second part is also
encoded with base 64. It is the token that
describes the user. And the third part in this
case is the digital signature for this token. And when we decode this
token– let’s base 64 decode it with the text result– we
see that this token is just a piece of JSON, a
piece of JSON that describes the current user. We see that the current
user got some rights– the right OpenID, the right
profile, the right email, and the right voucher. And we also see that this token
contains further information about the user, things we
could use for the authorization and authentication of the user–
things like the given name, things like the family name,
things like the email address, and whether the email
address has been verified, things like whether the user
can buy vouchers in bulk. So let’s look at the
message that we’ve generated by accessing
the resource server. I think for that I have
to buy some more vouchers. That looks great. Where is it? Here is it. And when we look at the
role, a few of these, we see that all of
these HTTP messages has an authorization header,
and this authorization header includes the token. So the client really
presents the token to the server to denote
that it has the rights to act on behalf of the user. So let me just give you a small
view to the code I’ve prepared. We don’t have much
time, so I will just show you the core of my
authentication solution. For this solution, I’m
using a small service I’ve written, a small library. This library provides me
with an OAuth service, and this service helps me
to do OpenID Connect as well as OAuth 2.0. And you’ll get all of
this code afterwards. You can download this code. I will post it on the
current Twitter stream, and all you have to do
is tell those service some specific data. You have tell those service what
the URL of the authentication server is. And you have to tell
that service what your URL is, the URL you
want to get redirected back after logging in. You have to mention the
name of your client. You have to mention the
scopes you want to get, the rights you want
to have delegated. You have to mention
the name of the issuer, and you have to say that you
want not only to do OAuth 2.0, but also OpenID connect. And then I have created
this convenience method. These convenience method
kicks in my OpenAuth service. It just setups it. It’s defined some state,
some [INAUDIBLE] state. Users that aren’t logged in
are redirected to this state, and then here we have
some callback method. This callback method is called
after we have been logged in, after we’ve received a token. And these methods
get some context. And this context
consists of an access token as well as of
the claims, as well as of the information
about the user we find within the
identity token. And I’m just taking
out the access token and creating a
default HTTP header with that, a header that is
sent to all the services we are accessing via [INAUDIBLE] HTTP. And in addition to
that, I’m reading the name of the user
to use this name to greet the user, and so on. So much to this
little demonstration. As mentioned before, you can
have all this code afterwards. So let me come to the
conclusion of all this. What did we see? We have seen that
OAuth 2.0 is primarily for the delegation
of restricted rights. We have seen that there
is something called the implicit grant,
and this implicit grant is for single page applications
that want to use OAuth 2.0. We’ve seen that
OpenID Connect defines how to do authentication
with OAuth 2.0, and we’ve also seen that OAuth
2.0 and OpenID Connect allows us for using central
user accounts, user accounts that we can
use for several applications. And we have also seen that,
when we are using OAuth 2.0, we don’t have to pass in our
passwords into the client. We just have to show our
passwords to the authorization server. So thank you for coming. And if you have
any questions, feel free to meet me at the
ask me anything room, or feel free to write me and
tweet the message, or an email. Thank you and have a nice day.

Bernard Jenkins

Leave a Reply

Your email address will not be published. Required fields are marked *