Single sign-on for mobile native applications
This is a modal window.
Das Video konnte nicht geladen werden, da entweder ein Server- oder Netzwerkfehler auftrat oder das Format nicht unterstützt wird.
Formale Metadaten
| Titel |
| |
| Serientitel | ||
| Anzahl der Teile | 170 | |
| Autor | ||
| Lizenz | CC-Namensnennung - keine kommerzielle Nutzung - Weitergabe unter gleichen Bedingungen 3.0 Unported: Sie dürfen das Werk bzw. den Inhalt zu jedem legalen und nicht-kommerziellen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen und das Werk bzw. diesen Inhalt auch in veränderter Form nur unter den Bedingungen dieser Lizenz weitergeben | |
| Identifikatoren | 10.5446/50629 (DOI) | |
| Herausgeber | ||
| Erscheinungsjahr | ||
| Sprache |
Inhaltliche Metadaten
| Fachgebiet | ||
| Genre | ||
| Abstract |
|
NDC Oslo 201470 / 170
2
3
5
6
8
11
12
16
21
22
23
27
31
35
37
42
43
45
47
48
49
50
52
54
56
57
58
61
65
66
67
71
74
77
80
81
83
84
85
87
88
89
90
91
94
95
96
97
98
100
102
107
108
112
114
115
116
118
120
121
122
123
126
127
128
130
133
135
137
138
139
140
141
142
143
144
145
147
148
149
150
153
155
156
157
158
159
160
161
162
163
166
169
170
00:00
Stochastische AbhängigkeitZugriffskontrolleIdentitätsverwaltungClientServerProtokoll <Datenverarbeitungssystem>AutorisierungPERM <Computer>AggregatzustandInformationAuthentifikationGoogolProtokoll <Datenverarbeitungssystem>Prozess <Informatik>PhasenumwandlungBildschirmmaskeSchnittmengeAutorisierungToken-RingOrtsoperatorPunktDatenflussVierzigVersionsverwaltungIndexberechnungInformationsspeicherungInteraktives FernsehenSelbst organisierendes SystemClientSystemaufrufPartikelsystemInstantiierungMobiles InternetMaschinencodeWeb SiteIdentitätsverwaltungServerKontextbezogenes SystemAuswahlverfahrenRelativitätstheorieKartesische KoordinatenWort <Informatik>BrowserPasswortURLMultiplikationsoperatorService providerNichtlinearer OperatorSchlussregelCASE <Informatik>Umsetzung <Informatik>BereichsschätzungBAYESGamecontrollerBitUmwandlungsenthalpieVorzeichen <Mathematik>DatenloggerFlächeninhaltEDV-BeratungWurzel <Mathematik>Ordnung <Mathematik>Gesetz <Physik>Endliche ModelltheorieDienst <Informatik>SoftwaretestStandardabweichungOffene MengeObjekt <Kategorie>GrenzschichtablösungInformationComputerspielDatensatzEigentliche AbbildungMereologieMehrrechnersystemFacebookBenutzerbeteiligungSingle Sign-OnAuthentifikationAbfrageTaskKlasse <Mathematik>MAPInverser LimesRichtungGüte der AnpassungKondition <Mathematik>E-MailNummernsystemComputeranimation
09:55
InformationAuthentifikationClientAutorisierungToken-RingServerIdentitätsverwaltungDigital Rights ManagementLoginStandardabweichungMobiles InternetPasswortPhysikalisches SystemPasswortInformationCASE <Informatik>Kartesische KoordinatenIdentifizierbarkeitMessage-PassingAdressraumQuick-SortMashup <Internet>AuthentifikationDienst <Informatik>DatenflussKontextbezogenes SystemVersionsverwaltungWort <Informatik>Deskriptive StatistikInformationsspeicherungExistenzsatzDateiformatHydrostatikProxy ServerDirekte numerische SimulationEinfügungsdämpfungMathematikIdentitätsverwaltungAutorisierungProtokoll <Datenverarbeitungssystem>NormalvektorSchnittmengeEinfach zusammenhängender RaumStandardabweichungE-MailToken-RingServerClientBrowserZweiTelekommunikationMereologieCodierung <Programmierung>Wurm <Informatik>Elektronische UnterschriftGruppenoperationNetzadresseBenutzerbeteiligungService providerMAPZeichenketteMobiles InternetMaschinencodeWasserdampftafelWald <Graphentheorie>PunktSchwingungDigital Rights ManagementSystemaufrufForcingIndexberechnungPartikelsystemEinflussgrößeGeradeMetropolitan area networkBenutzerschnittstellenverwaltungssystemOffene MengeFormation <Mathematik>Stokes-IntegralsatzBenutzerfreundlichkeitVierzigBitrateEinfache GenauigkeitVorzeichen <Mathematik>GamecontrollerAggregatzustandBildschirmmaskeWurzel <Mathematik>Inhalt <Mathematik>Automatische DifferentiationRichtungProzess <Informatik>Basis <Mathematik>DreiBAYESStreaming <Kommunikationstechnik>Skalarprodukt
19:51
PasswortServerAutorisierungInformationClientRelation <Informatik>AuthentifikationMaschinencodeSichtenkonzeptPhysikalisches SystemBrowserEingebettetes SystemKontextbezogenes SystemDemo <Programm>KardinalzahlLoginToken-RingPasswortAuthentifikationServerLoginE-MailClientMaschinencodeRelativitätstheoriePhysikalisches SystemBrowserInformationsspeicherungInformationAttributierte GrammatikKonfigurationsraumDatenflussKartesische KoordinatenSichtenkonzeptNormaler OperatorExpertensystemStrategisches SpielGamecontrollerStellenringKontextbezogenes SystemAutorisierungApp <Programm>IdentitätsverwaltungEinfügungsdämpfungMAPComputersicherheitResultanteFacebookEndliche ModelltheorieMaßerweiterungInstantiierungCASE <Informatik>TeilmengeNummernsystemMathematikHumanoider RoboterBus <Informatik>BenutzerschnittstellenverwaltungssystemTeilbarkeitVersionsverwaltungUmsetzung <Informatik>URLPunktWeb-SeiteTablet PCSoftwareentwicklerWurzel <Mathematik>FlächentheorieSystemaufrufWellenlehreSkalarproduktCOMYouTubeRechter WinkelComputerspielWasserdampftafelEinfach zusammenhängender RaumAggregatzustandLastBenutzerbeteiligungBeobachtungsstudieLineare RegressionGeradeGoogolComputeranimation
29:46
AuthentifikationSichtenkonzeptMaschinencodeClientCookie <Internet>Demo <Programm>LoginApp <Programm>Service providerWeb SiteIdentitätsverwaltungAutorisierungServerKanal <Bildverarbeitung>Prozess <Informatik>Digitales ZertifikatGanze FunktionProzess <Informatik>TelekommunikationSingle Sign-OnPhysikalisches SystemMultiplikationClientKartesische KoordinatenSichtenkonzeptBrowserService providerBestimmtheitsmaßWeb SiteInformationPasswortInformationsspeicherungPROMServerWort <Informatik>Token-RingBildschirmmaskeDateiformatVorzeichen <Mathematik>Arithmetisches MittelIndexberechnungInstantiierungZweiSystemaufrufEinsGeradeEnergiedichteCookie <Internet>Wald <Graphentheorie>MaschinencodeUniformer RaumBenutzerbeteiligungPhysikalischer EffektHumanoider RoboterMultiplikationsoperatorMAPBootenApp <Programm>GoogolDifferenteDemoszene <Programmierung>Lie-GruppeRechter WinkelGüte der AnpassungIdentitätsverwaltungPunktDatenflussMobiles InternetFlächentheorieSchnelltasteQuick-SortEinfache GenauigkeitEinfügungsdämpfungUmwandlungsenthalpieWeb-ApplikationAuthentifikationEndliche ModelltheorieUnternehmensarchitekturDigitales ZertifikatCASE <Informatik>Attributierte GrammatikKonstanteAutorisierungLoginProgramm/QuellcodeComputeranimation
37:29
Protokoll <Datenverarbeitungssystem>ServerDienst <Informatik>Software Development KitHumanoider RoboterGoogolProgrammbibliothekMaschinencodeElektronische PublikationDigitales ZertifikatAliasingSpielkonsoleClientAuthentifikationE-MailSchlüsselverwaltungRFIDZeichenketteBenutzerprofilToken-RingGruppoidAusnahmebehandlungDemo <Programm>Ganze FunktionTechnische InformatikInterface <Schaltung>CASE <Informatik>Nichtlinearer OperatorResultanteGoogolAutorisierungBenutzeroberflächeInformationTaskKontextbezogenes SystemSerialisierbarkeitBildschirmmaskeInstantiierungKonstanteTouchscreenMultiplikationsoperatorKartesische KoordinatenProtokoll <Datenverarbeitungssystem>Dienst <Informatik>Digitales ZertifikatSpielkonsoleClientProzess <Informatik>DifferenteHumanoider RoboterE-MailToken-RingAuthentifikationImplementierungMaschinencodeSichtenkonzeptHash-AlgorithmusElektronische UnterschriftKreisflächeInstallation <Informatik>SchlussregelProgrammierumgebungSystemaufrufProgrammbibliothekDateiformatEinsZweiTermAusnahmebehandlungZentrische StreckungMinimalgradRichtungTwitter <Softwareplattform>Wort <Informatik>Konfiguration <Informatik>Physikalischer EffektComputeranimation
45:12
Token-RingAutorisierungServerClientAuthentifikationDienst <Informatik>MenütechnikWarpingDemo <Programm>Kartesische KoordinatenServerClientDienst <Informatik>SichtenkonzeptHumanoider RoboterProfil <Aerodynamik>SchlussregelInformationsspeicherungProzess <Informatik>SoundverarbeitungMultiplikationsoperatorInformationGruppenoperationMAPKonstantePropagatorDigitales ZertifikatProjektive EbeneIdentitätsverwaltungBeobachtungsstudieAggregatzustandGeradeOffice-PaketUmfangWeb-ApplikationOffene MengeDatenflussDifferenteInverser LimesBereichsschätzungToken-RingAuthentifikationMaschinencodeSpielkonsoleCASE <Informatik>ParametersystemHash-Algorithmus
49:57
RechenwerkSpieltheorieToken-RingServerClientAutorisierungDienst <Informatik>GoogolHumanoider RoboterApp <Programm>MaschinencodeAtomarität <Informatik>ZeichenketteTouchscreenServerTaskClientBenutzerschnittstellenverwaltungssystemProfil <Aerodynamik>MaschinencodeToken-RingGoogolMomentenproblemInhalt <Mathematik>SchnittmengeCASE <Informatik>Lie-GruppeZusammenhängender GraphInformationKartesische KoordinatenDienst <Informatik>Wald <Graphentheorie>BenutzerfreundlichkeitComputerspielProzess <Informatik>URLPunktE-MailIdentitätsverwaltungDatenfeldEinfach zusammenhängender RaumComputeranimation
55:31
SpeicherabzugToken-RingTelekommunikationApp <Programm>ServerIdentitätsverwaltungGeradeServerTaskKartesische KoordinatenClientMailing-ListeMaschinencodeToken-RingInteraktives FernsehenAutorisierungMultiplikationsoperatorZahlenbereichCASE <Informatik>Selbst organisierendes SystemSingle Sign-OnDienst <Informatik>VierzigMaschinenspracheIdentitätsverwaltungProtokoll <Datenverarbeitungssystem>DatenflussDigital Rights ManagementInstantiierungZehnFacebookTermIntegralOffene MengeSystemaufrufSichtenkonzeptDemoszene <Programmierung>FunktionalWeb SiteSelbstrepräsentationGoogolInformationResultanteEinfach zusammenhängender RaumSoftwareentwicklerBenutzerbeteiligungNichtlineares ZuordnungsproblemPhysikalisches SystemBrowserPunktRepository <Informatik>ComputerspielDreiecksfreier GraphEinbettung <Mathematik>Element <Gruppentheorie>Interface <Schaltung>Gesetz <Physik>IdentifizierbarkeitInhalt <Mathematik>AuthentifikationApp <Programm>EinfügungsdämpfungSoftware Development KitZweiDifferenteDemo <Programm>
Transkript: Englisch(automatisch erzeugt)
00:01
Okay, I think I'm going to start. Hello, good afternoon. Thank you for being here in the last slot of the day. My name is Pedro and for the next hour I'm going to be talking a little bit about how to do proper authorization authentication and having single sign-on on mobile web applications.
00:22
I'm going to divide my session in four parts. In the beginning I'm going to talk a little bit about token-based access control, at least what is common practice right now to do token-based access control. Then I'm going to talk a little bit about the specifics of mobile clients and
00:43
the challenges that mobile clients introduce when we are dealing with token-based access control. I will talk about a single sign-on for mobile devices and having multiple applications using the same sign-on on a mobile device.
01:01
I will talk a little bit also about hybrid clients that are divided between some code that is running on a device and some code that is running on the server side. I will end with some review of what is coming in this area. Before I start, I'm a teacher at Lisbon. I'm also a consultant. I'm mainly a server guy, so a server side guy.
01:27
I work with APIs, also identity and access control. I'm the co-author of this book, Evolvable Web APIs, that was published around April this year. It's selling downstairs with some interesting discount today, I've been told.
01:44
Well, without further ado, 2014, token-based access control. If you have a client application that wants to access a resource server and has to add something to the request in order to be allowed to access the resource,
02:04
the common way today is to append or attach an access token. For instance, the proper way is via the authorization header in HTTP using, for instance, the bearer scheme.
02:20
It is also possible to insert access token when I'm doing a form URL encoded post inside the body. The standard even allows to add the access token on the URI, namely in the query string, but please never do that because URIs leak everywhere, so our tokens are going to be leaking to log files,
02:46
to logcat, for instance, and other places where access tokens should not be. Okay, so if a client application, server side or client side, or server side or device side,
03:02
wants to access a resource server, it uses an access token. So in our model, we have client applications, we have resource servers, but we have also other characters. Namely, we have users, which are not clients, are humans, typically that own some resources on the resource server.
03:23
For instance, if the resource server is the Google API, I may have a calendar or I may have tasks that are here, so I'm the resource owner of those resources, and I'm using a client application to manage those resources. We also have a fourth character in our class of characters, which is the authorization server that is going to manage the tokens.
03:47
Namely, it is the authorization server that issues the tokens and manages the lifetime of these tokens. Finally, we have a protocol, which is OAuth 2.0, which is rather common nowadays,
04:04
that allows the client application to obtain tokens. Now, there are mainly two different ways. One of the ways is what is called a resource owner username and password, in which the resource owner, the user, provides her username and her password to the client application.
04:25
The client application exchanges that username and password for an access token, and then uses the access token when it wants to access the protected resources. So, this is one of the ways. The password doesn't have to be stored here,
04:42
it just has to be exchanged one time via this token endpoint for the access token, and then what has to be stored is the access token. So, a reduced risk of leaking the password. This way of obtaining tokens has one main advantage,
05:02
that is, it implies that the password for my account on the resource server has to be delivered, has to be inserted directly in the client application, which may not be a good scenario depending on the relation between the client application and the resource server.
05:23
For instance, I may not want to insert my Google credentials on a third-party application, on which I have a low level of confidence, for instance. The second way of obtaining tokens is via browser redirects. In this way, the client application redirects the browser of Alice, in this case,
05:43
to one point called authorization endpoint, using an authorization request. Afterwards, there is some kind of conversation directly between the authorization endpoint and Alice's user agent. Typically, this is the phase where Alice is going to authenticate herself to the authorization server,
06:05
using username and password, or using federated authentication, for instance, with a third-party identity provider. This is also the phase where Alice is going to consent on some form of authorization,
06:20
or this is a phase where Alice is going to allow that the client application performs some kind of operation, limited operation, on her resources in the resource server. Finally, the authorization endpoint is going to respond with a code, an authorization code, or with an access token.
06:42
In this variant here, the client receives the access token and then uses the access token directly. The flow is done. If the client application receives the authorization code, instead there is a third phase where the client application has to exchange the code
07:01
and jointly with the client credentials obtains the access token and delivers the access token to the resource server when the client needs to access those resources. So, we have a first version where the credentials are inserted directly into the client application.
07:24
There is no need for a browser-like user agent in this flow. We have a second flow that requires a browser for the interaction between the client, the resource owner or the user, and the authorization server.
07:41
So, this is the first context that we have to have before we deal with the specific subject of mobile authentication. The second issue is using OAuth 2.0 for authentication. OAuth is not an authentication protocol. It is an authorization protocol.
08:04
However, it is often used to authenticate users. For instance, it is common to have some sites that use GitHub authentication and use GitHub authentication via OAuth 2.0.
08:20
The same is happening for Google now. Facebook uses a variant of OAuth 2.0 also to obtain authentication. How is that possible if OAuth is not an authentication protocol but instead an authorization protocol? Well, typically all these scenarios where OAuth is being used for authentication
08:42
are based on an ADOC user info resource that is provided by the resource server and that the client application uses to fetch some identity attributes from the user. For instance, if the client application possesses an access token that was granted by a user,
09:03
it can use this access token, access for instance the GitHub API on the slash user endpoint, and obtain a JSON object with several details from the user. So, it is using this specific resource from the GitHub API to obtain information
09:24
and via authorization authenticate the user. But this is always something that is outside of the protocol because it uses specific endpoints that provide user information and that require this access token.
09:42
For instance, LiveID operates in the same way and has this resource here exposed in this URI. However, this kind of authentication where I'm using an opaque access token to access a user info resource and then obtain a set of identity attributes,
10:04
it's risky. It's very risky because I'm using a bearer access token for authentication and bearer access tokens are mainly created for authorization. They are not, in the general sense, they are not safe to be used for authentication.
10:23
Because when I'm using a token to authenticate some entity, I must be assured that the token that I'm receiving was intended from me. Because if the token was not intended from me, it can be used by a third party on which, for instance, Alice authenticated.
10:41
The third party now is reusing Alice's token to impersonate Alice when he wants to access my service. So there are some uses of OAuth 2.0, namely using the code flow with confidential clients where this kind of usage is secure, but we must be aware that in the general case it is not.
11:06
So, be aware that this kind of practice is not completely safe. Namely, there is one important thing that we must always check when we are using
11:21
some form of token to authenticate a party, is that we ensure that the token was intended for us and not to another party. To address these shortcomings of the OAuth 2.0 protocol in respect to authentication,
11:40
there is a new protocol which entered version 1.0 around a couple of months ago, which is OpenID Connect. And OpenID Connect is a simple identity layer on top of OAuth 2.0. However, I'm always afraid of protocols that have the word simple in the description.
12:05
In this case, OpenID Connect adds the following on top of OAuth. It adds the concept of an ID token. The access token for the client application is an opaque string.
12:21
The client application doesn't have any visibility on the access token. Is this the reason? The existence of the user info resource is due to that opaqueness of the access token. For the client application to learn anything about the user that is connected to this access token,
12:43
it must use this user info resource. The ID token or the JWT ID token, the JSON web token format, is a defined format that the client application can use to look inside and obtain identity claims, identity attributes from the user that is providing the token
13:08
or that is allowing the token to be issued. So OpenID Connect, one of the things that OpenID Connect layers on top of OAuth is the concept of an ID token.
13:20
The other item that OpenID Connect adds on top of OAuth is a normalized user info resource. Instead of each provider having its own version with its own format and with its own way of interacting for the concept of a user info resource,
13:42
the OpenID Connect defines a well-specified way of providing this information given an access token. The way that the user info resource is used is typically I send the access token and I get a bag of user claims back
14:02
that I can use to obtain identity information about the user. Note that if I'm talking about mobile device authentication, my final goal is for the application that is running here to obtain,
14:20
with some level of assurance, identity attributes, identity claims of the user. So this is the subject of the authentication and this is the relying party that needs those identity claims. Okay, moving on.
14:41
The JWT ID token is a text-based format that is typically composed by three strings, three base 64 URL encoded strings separated by dots. The first one is the header or is the base 64 URL encoding of the header.
15:06
The second part is the base 64 URL encoding of the body or the payload of the token and typically the last part is the signature of the token to ensure that the token was not changed while in transit.
15:24
The most interesting part of a JWT token is the body and the body provides this information. It provides information about the issuer of the token, in this case the identity provider, the audience of the token,
15:42
which means the only entity that should use this token to authenticate the subject. For instance, if I'm an application that wants to authenticate the user and I receive a token and the identifier that is here is not my identifier,
16:03
I should immediately reject the token and not use it for authentication. So when I'm on the receiving side of the authentication and I receive a token, the first thing that I should do is ensure that the token was targeted to me, was issued by the identity provider to me and not to another party.
16:25
It has an expiration date, it has an issue date, and it has a set of claims about the subject that is being authenticated, in this case, Alice. Okay, so resuming, the OpenID Connect adds the concept of ID tokens
16:48
that are piggybacked on top of the OAuth messages and also defines the concept of a standard user info endpoint. Also, it defines some standard claims, namely to ensure some level of interoperability.
17:03
It defines an address claim, an email claim, an email verified claim. And it also provides some sort of session management, namely to achieve a single sign out. So where we are, we have token-based access control,
17:23
we are using OAuth 2.0 to obtain those tokens and we are using OpenID Connect to layer authentication on top of the authorization provided by this protocol. But these protocols were mainly designed for client applications
17:41
that are running on the server. Namely, the concept of OAuth appeared a couple of years ago to support mashups that were running entirely on the server side. And the subject of this talk is client applications that are running on the device side.
18:01
And when the client application is running on the device side, it introduces some challenges. And what are those challenges? First of all, when the application is running on the server, it is rather easy for this application to store secrets. Namely, the client credentials that are issued when the client is provisioned.
18:24
Also, since this is a server, it is also rather easy to host redirect endpoints where this authorization server redirects the LSS browser when this flow is done. However, when the client application is running on the device,
18:43
first of all, it's very hard to store static secrets on the device. Namely, if I store the client secret on the APK, for instance, it's rather easy to extract that secret.
19:00
Also, it's rather easy to create a man-in-the-middle proxy that intercepts the communication and it obtains that secret. So, first problem, storing secrets. The second problem is hosting redirect endpoints. Typically, it's not easy for me to host your server with public IP and public DNS.
19:23
So, these are the first challenges. There are mainly three ways of addressing these shortcomings. The first one is not to use browser-based flows. Use the first one, the resource owner password credentials,
19:41
where the user inserts the username and the password in the native UI. The system changes immediately the password for the access token, stores the access token, and uses the access token on the resource server, and deletes the password. This is the simple solution.
20:01
However, it involves inserting the credentials directly into the application, which may not be allowed for certain scenarios. For instance, if I'm a third-party application that is consuming the Google API or the Facebook API,
20:22
it's not allowed for me to accept the Google password or the Facebook password inside my application. Also, if the authentication that is used by the authorization server is not password-based, for instance, it's password plus a second factor,
20:41
there is no support in this model for such extended authentication. This provides a better UX because this UI is completely native. It's simple to implement. However, it is limited to username-password authentication.
21:02
I don't have two-factor authentication. I don't have federation, for instance. The password is inserted directly in the application UI, which only makes sense when there is a trust relation between who developed the application and the resource server and authorization server.
21:23
So it assumes a certain level of trust between clients and resource servers, authorization servers. The second approach is to use our token or code flow, but in this case I have to host a browser-like user agent.
21:41
And here I have two ways of dealing with this. The first one is to use the system browser. What this native application does is to launch the system browser. For instance, on Android I can create an intent using the request, the authorization request URI.
22:05
I send the intent. The system browser accepts intents for URIs, which are HTTP. It launches the system browser, redirects the user to here. The user interacts via system browser with the authorization endpoint,
22:21
namely to insert our credentials, to consent the application to use some subset of our resources. And finally, I have to handle the redirect again into the client. When I'm using the system browser, the most common way of doing this
22:41
is using custom URI schemes to handle that redirect. So instead of redirecting to an HTTP URI scheme, I will redirect to a custom scheme that was previously associated to this application.
23:02
So in the case of Android system, I will do inside an activity, I will declare an intent filter that states that it is able to receive custom scheme URIs requests. However, this kind of solution is not used often
23:23
because it moves the user away from the application. When the user tries to authenticate, the context of the user's context changes to an outside application, which is the browser. And typically, the user experience experts
23:41
don't like this experience and even forbid this experience, where to use an application, I'm driven to the outside of the application. So the second way is to use an embedded WebView. In this case, I create a WebView.
24:01
I load a starting URI, which is the authorization request URI. The user uses the WebView to interact with the authorization endpoint, to insert the credentials, to consent on the use by the client.
24:20
And finally, on the redirect, I use a different strategy. Because since the embedded WebView is running inside the application, I have complete control on what the WebView is performing. Namely, I can intercept all the HTTP requests that are being done on the WebView.
24:42
For instance, I can configure a local host redirect URI and intercept the request to the local host and stop the WebView, obtain the URI, which has the code or the token there, and close the WebView and proceed with the normal operation.
25:06
The main advantage is that since I control the embedded WebView, I can't have more controlled authentication and consent flows. It has another advantage, which is the user remains in the application context.
25:22
Namely, if the HTML that is running in the embedded view is done with special care, the user doesn't even notice that it commuted from the native context to a WebView context.
25:41
The main problem is that the credential usage is not isolated from the app. A malicious app can obtain every information that the user inserts in a WebView that the application is hosting. The system browser provides a level of isolation because it's another application.
26:01
So it is not supposed that my application has access to the credentials that are inserted in the system browser. But if the credentials are being inserted inside a WebView that is embedded in my application, the application has access to everything. So it's almost the same as receiving the username and password
26:21
directly into the application from a security viewpoint. So I will do a little demonstration using WebView to authenticate to GitHub. So I have Eclipse. Let's start.
26:57
It is a login button. I start the login button,
27:02
and I'm redirected to the GitHub authorization endpoint. Since the user is not authenticated, the GitHub redirects to the login page, and I insert my credentials.
27:30
Okay. And what I'm seeing here is the result of accessing the slash user endpoint at GitHub to obtain the user information.
27:41
Namely, I obtain the login name, and somewhere in this JSON should be the email and other identity attributes of the user. How was this done? Well, we can look at the logcat. I started by creating a WebView. I pointed the WebView to the authorization endpoint,
28:03
passing my client ID. Then I configure a WebClient, which is associated to the WebView in Android, which is constantly looking into the URIs that are being loaded into the WebView. For instance, I see that this URI is loaded,
28:23
and I check if it is the redirect. It isn't. So, should load github.com? Yes, because it is not the redirect URI. Should load github.com authorized? Yes, because it isn't the redirect URI. Should load localhost?
28:40
No. What means should not load? The WebView doesn't have to load this URI because this URI is the redirect URI. So, I end the WebView. I have the URI in possession, so I can obtain the code which is here.
29:01
And then I proceed to exchange the code for the access token using the client credentials, which I obtain in this JSON here, and then I use the access token to obtain the user information which I'm presenting here.
29:23
Okay, makes sense. One problem that you must be aware of is that since GitHub only supports the code flow with confidential clients, that is, clients that have a client secret,
29:40
I have to embed the client secret on my application. This means that the client secret is not a secret anymore, but I have to be aware of that consequence. So, I have custom code to detect the redirect URI. I have an embedded client secret, which means that it's not a secret anymore.
30:02
You must be aware of storage cookies. For instance, I have special code on my WebView to delete the cookies. If not, the cookies are stored and the user is logged in always, which may not be what the user expects.
30:23
So, you should provide some form of cleaning up the authentication cookies so that the user has some form of logout experience. Okay, moving on.
30:40
However, I can use a WebView to obtain tokens via the OAuth 2.0 flows, but if I have multiple applications that require Google authentication or GitHub authentication or authentication against my enterprise identity provider,
31:03
the user has to insert the password in the little keyboard multiple times. So, it would be interesting, it would be nice if we could provide some sort of single sign-on, where the user inserts the credentials only once,
31:23
and those credentials can be used to obtain tokens for multiple applications. So, can it be better? Can we have single sign-on for mobile apps? Well, before addressing this theme, let's see what does it mean
31:41
to have single sign-on for web clients or for web applications. So, when a typical single sign-on scenario, Alice wants to access a website, which we call Relying Party. The Relying Party doesn't have information, doesn't have identity information about Alice,
32:01
so, sorry, redirects Alice via the browser to an identity provider. The identity provider authenticates Alice, for instance, using a username and password, and creates an authentication session, typically in the form of a cookie. And this cookie is stored in the user agent.
32:22
Then, it issues an identity token, targeted to this site, so that the site can obtain with some level of assurance the identity attributes of the user. If Alice wants to access another website, the second website will redirect again to identity provider,
32:42
but this time there is a cookie, which means that Alice doesn't have to authenticate anymore. Perhaps Alice has to consent that this site receives the identity attributes, which is a yes or no decision, but she doesn't have to authenticate anymore. And finally, an identity token is issued to the second website
33:06
using a different audience. So, what we want is to replicate in a mobile device this kind of experience. How? Well, making the mobile device taller.
33:24
Why? Because now the mobile device will have one thing that I call, and a specification that is being developed, but calls a token agent. And what is the token agent? Is the entity running inside the device
33:41
that is used by the application to obtain identity and to obtain tokens? So, when Alice tries to launch the application, the application calls the token agent to obtain tokens about Alice. Mainly tokens that define Alice's identity
34:00
and tokens that allow the application to access the resources that are hosted here. What happens next? Well, typically this token agent will ask Alice for her identity information. She will have to insert the username and the password.
34:22
The token agent will send this username and password to the authorization server and will receive what I call a primary token. This primary token identifies or represents the authentication that Alice did here.
34:42
Next, the primary token is saved and is used to obtain a specific token to this application. So, this primary token is similar to a cookie that the browser stores when an authentication session
35:00
was created with an identity provider. And finally, the token is sent to the application. The primary token is stored in the token agent. Typically, the tokens are only issued to the application if there is some constant that Alice must provide.
35:21
If now Alice wants to use a second application, well, the second application asks for tokens to the token agent. The token agent already contains the primary token, uses this primary token to obtain the specific tokens to the application.
35:41
So, no need for username and password, no need for authentication. What typically should happen is only a constant that Alice's constant that the system provides to this application, some form of identity formation and some authorizations for the application
36:02
to use Alice's resources here. So, this is the abstract view of this model of having a single sign-on inside devices. From a technological stand, what do we have today?
36:21
Well, before that, some things that I would like to highlight. First of all, the application doesn't use browser redirects to communicate with the identity provider. It uses inter-process communication, which means that I can use some form of application authentication
36:43
which is not based on secrets, but which is based on, for instance, package names and package certificates in the case of Android. So, this token agent that is running here is able to obtain some identity information
37:03
about this application that is being provided by the Android system. Of course, if my device is rooted, I can pretend to be anything. So, something that we all should be aware of. Also, the user credentials and consent are inserted directly
37:23
in the token agent, which means that the token agent can provide a uniform authentication and consent experience without different UIs and different behaviors being provided by each one of the applications. The protocol that exists here nowadays is a custom protocol
37:44
because neither open ID connect defines what can happen here. Finally, I should stress that the primary token is stored only here and not accessible by the applications.
38:02
Okay, so from a technological viewpoint, what do we have now? Well, there are multiple implementations of this concept. One that I'm going to show today is using Android and using Google. When I install Play Services, I'm installing a token agent,
38:24
which I can use via the Play Services SDK. So, used to what? Used to authenticate the user against Google services and used to access the user resources in the Google API.
38:47
How can I achieve that? Well, first, I must import the Play Services library. It is available in the SDK. I also must obtain, in case of a debug environment,
39:01
I must obtain the debug certificate that is being used to sign the APKs. Then, I must go to the Google API console and provision a client. In this case, I provision an installed application, say that is an Android application,
39:20
and then I must provide two items of information. The first one is the package name, and the second one is the hash of the certificate that is being used on the signature of the APK. These two items of information will be used to authenticate,
39:42
to obtain information about the requesting application by the token agent. In this case, by the Play Services that are running on my phone. Okay, so, I've imported, I've installed Play Services,
40:00
I've imported the Play Services SDK, I've provisioned my client, what must I do next? Well, I can use account picker to present a user interface that shows the available accounts or allows the user to create a new account or to select a new account to be used on the device.
40:22
The outcome of this process is an email, which, in the case of Google, uniquely identifies the user. Since we may be talking about operations that require IO, this process is asynchronous, so what I receive here is an intent,
40:40
and I start the activity for this intent. This is handled by activities that are provided by Google. In the end, I must implement the result of the activity and fetch the value. Here I have one activity result. I go to the resulting intent,
41:00
and given this key, I obtain the account name, which, in Google's case, is an email. So, now I have an email, but I must confirm the identity, and if I want to access Alice's resources, I must obtain an access token. For that, I will use this static method
41:20
of the Google author tool, which give an email, and the scope returns a token. Be aware that this is a blocking operation, which I typically must perform on an async task or something that will not block the user interface.
41:42
Also, be aware that the obtainance of a token might require user interaction, which means that this process can end with an exception, and I go inside the exception, obtain an activity, start that activity,
42:03
to allow Google to interact with, or to allow the Play Services to interact with the user. This is done by this. There is a special exception, which is called user recoverable authentication exception, and if the GET token ended due to this exception,
42:23
then I must fetch an intent that is inside the exception, which is rather odd, but it is what it is, and I must start an activity using that intent. This activity typically will ask the user for some form of consent, for instance.
42:43
Okay, and finally, I get the token. So, I will try to demo this. All the code will be available on GitHub. I hope that my credentials will not be there. Oh, well, let's see.
43:03
Let's go to Google Client. Okay, here we are. So, I start by clicking this button to log in with Google. In this phase, I'm trying to obtain an account.
43:23
I have two options. Use an account that is already provisioned in the device, or add a new account. I will select this one. And then there is a constant screen that appears, because this is the first time that this application
43:42
is being allowed on my device. Namely, Alice can observe that the application will be allowed to view basic account information. I will say yes. Okay, and now I have the user info.
44:01
I have a token, and I also can use this token to obtain the user info. So, this is the outcome of a user info request using the token that I've obtained. I could also do something like this, where I decide to add an account.
44:51
Again, constant screen, yes. Okay, and I have Bob's information.
45:05
Make sense? Okay, moving on.
45:23
However, there is a limitation in this process. Most of the times, I don't only have an application that is running the device side that wants to access user information and the resources that are here. Most of the time, I have a server side
45:43
of this client application. And one of the things that this application may want to do is to store, for instance, information in the user's account. And for that, the server side must know
46:01
with some level of confidence what is the identity of the user. So, how can the client application that already authenticated the user propagate that information to the client side? Well, one way is to say, well, it's Alice, trust me.
46:25
Since there are no secrets, there are no static secrets in an application, it is not secure to use this approach of I'm your device side application, so if I'm talking to you, trust on what I do,
46:40
on what I say. It's not possible. So, we could use the access token that this application has to authenticate the user to the server side. However, as I've said before, opaque bearer tokens should not be used
47:02
for authentication and this use case is not secure also. We could try to use an ID token that is issued to the device side. However, such an ID token will not be accepted by the server side because the client ID is tied to here and not to here.
47:23
Because if this application requests an ID token, the audience of the ID token will be this application and not this one. So, what would be proper would be for the application to obtain an ID token
47:40
that is issued to the server side and not to the device side. I tend to use client side, but they are both clients. They are both client applications. How can I do this? Well, in the case of Play Services, one of the parameters that I define
48:01
when I ask for a token is the scope. The first scope that I've used, and I have here in the code somewhere, the first scope that I've used was rather simple. I want email, I want profile, and this is an open ID flow.
48:21
But now I'm asking for something a little bit different. I'm asking for an ID token which should be issued not for this client ID, but for the server side client ID.
48:40
So, before I perform this request, I must go to the Google API console and provision a server side client. I have my Android application, which is here. So this is the package name and this is the hash of the certificate.
49:00
And then I provision a web application which will have a client ID, a client secret, which will be stored on the server side. That is, it is in fact, or can be in fact, a secret. And I define normal HTTPS's redirect URIs. Since these two clients
49:23
belong on the same Google API project, this means that this client can request an ID token that is targeted to this client here. So, let's see this happening.
49:45
Okay. I've already authenticated. Now I'm going to request an ID token for the server. And here I have the ID token. It was fast. If you go to log cat, let's try to...
50:15
I resized the screen and then this happens.
50:26
You are going to have to trust me. What happened here, and I will show the details of the ID token in a moment. What happened here was that
50:42
I've asked the token agent for an ID token targeted to this client application. The token agent uses the primary token to obtain the ID token. The device side obtains the ID token and then delivers the ID token to the server side. The audience of this ID token
51:01
is the server side and not the client side. This is the content of the ID token. And you can see that the audience in this case is the audience of the... Well, you cannot see, but you have to trust me. This ID is the ID of the server side
51:22
while this ID here is the ID of the device side. And this claim AZP, which stands for Authorized Party, is something that was defined by OpenID Connect and tries to say this.
51:42
This ID token was requested by this client but to be consumed by this client. So this ID token has four main components of information. First, the issuer. Who issued the ID token? Google did it.
52:00
Then identity claims on the user, the subject and the email. Then the target of the ID token, the only entity that should accept the claims that are in ID token because the audience field matches its identity,
52:21
which is the server side. Finally, it is also included, this Authorized Party, that allows the server side to know that the requester of this ID token was the device side, was the application running on a device.
52:42
Moving on. Third problem. What if this client application wants to access a resource running on Google, for instance? Namely, what if this client application wants to access this resource when the user is not interacting with the application anymore,
53:03
when the user is offline? So this server side client application must obtain an access token. But typically, the access tokens that are provided to this device side client application are short-lived. Well, in the case of Play Services,
53:23
we can make this application ask for a code, deliver the code to the server side, and then the server side completes the process by requesting a token from the token endpoint and providing it to the resource server.
53:42
Something like this. I ask for a code. The request is the same. I call the GetTokenStatic method, but the scope that I provide is different. In this case, the scope is server, where I pass the client ID of the server side, and then I pass the scopes that I want
54:03
that the server side should be able to access. In this case, I'm passing the email, which means that the server side can query the email, and this scope here, which means that the server side is allowed to read the tasks of the user. So let's see this running.
54:27
It is here. Get code for server. Now, the token agent is asking me if I allow the application to view my tasks.
54:42
I did consent that the application should be able to access my profile and email, but I didn't add consent in the past that the application should be able to view my tasks. Now I'm going to say yes,
55:02
and here I have a code, which I will not be able to copy from here. It is here.
55:24
Let me try something. Ah, it's here. So I go here, and I pretend that I send this to the server.
55:43
I have here an application that is pretending to be a server. I insert the code, and the server application uses its stored client secret to exchange the code for an access token and then uses the access token to retrieve,
56:04
in this case, the tasks. So I can see that there is a task list which is NDC Oslo 2014. Make sense? Yes? Okay.
56:22
So moving on. In this case, just to recapitulate, I ask not for a token, not for an ID token, I ask for a code that should be usable
56:42
by the server-side client application, and the authorization via the token agent provides the code to the device side, which then sends the code to the server side. The server side exchanges the code for an access token using the client secret that is stored only here,
57:04
and then with the access token can access not only the user info, but for instance the task resource that is here. So moving on. This is a custom solution.
57:20
It's a custom solution because it is using custom scope prefixes. It is using a custom SDK to interact with the token agent. It is also using a custom and opaque protocol that I don't have any visibility on it between the token agent and the authorization server.
57:41
There are other custom solutions. For instance, when I install the Facebook application on the Android, I'm also installing a token agent that I must use a different SDK and that probably uses a different protocol to talk to Facebook servers. What would be nice
58:01
would be to have a standard solution for this scenario. And this is what is being developed by the OpenID Foundation on top of OpenID Connect. So probably we will have another simple layer this time on top of OpenID Connect
58:22
to handle the management and single sign-on functionality for native applications. They call it NAPs. It is based on the concept of a token agent. Namely, I use the token agent term because it is defined here,
58:40
which is a device-side representative of the authorization server. It defines that the token agent must use the code flow to obtain the primary token, which probably means that WebViews are going to be involved in this. This WebView will handle user authentication and user content.
59:03
The result of this code flow is the obtainance of a primary token, and then the token agent uses the primary token to obtain secondary tokens to each one of the apps running on the device. It also aims to define
59:22
how the apps are going to communicate with the token agent without requiring a special SDK for each integration scenario. Probably it is going to be based on sending intents and register activities for the callbacks from the token agent.
59:46
As far as I know, there is no support yet for delegation to server-side, which was the second example that I've showed. No, for device identity, which is also a good requirement.
01:00:00
or a nice requirement to have, because I should be able to have visibility on the authorizations that I have gave for each different device that I'm using. So, and with this, I end my talk. With regards to resources, if you are interested in OAuth,
01:00:21
it is defined by the RFC 6749 and 6750. All the information to create these demos were available on the developer site from Google. The information about this new, simple layer on top of OpenID Connect, NEPs, is available here. In my book, I also have a chapter only about OpenID Connect
01:00:44
and OAuth 2.0, which is selling with a special price today. This code will be available on my repo, and with that, I thank you for your patience and for being here, and I'm available for questions.
01:01:07
Questions? Yes. I can use that, but sessions on a web view
01:01:25
will not be shared between applications. With the system browser, they would be shared. It depends if I, it depends also on the life cycle of the system browser.
01:01:42
Yes. Yes, yes, yes. In this example that I've showed, I used a web view, but I can, instead of creating and embedding a web view, I can launch a system browser via an intent, for instance.
01:02:06
No, no, no, no, no. When I design the app, I must decide if I'm going to use an embedded view or the system browser.
01:02:25
Sorry, I'm not understanding your question. Yes, of course. No, no, no, no.
01:02:41
I cannot be assured that the user agent that is contacting the authorization server is not the user browser, because on a web view, I can replicate everything that the user, the system browser sends. User agent, others, everything can be equal.
01:03:02
So probably, I would not be able to distinguish automatically on the authorization server. I think if I'm running an authorization server, and I want the users to only use the system browser, I have to educate the users and eventually have UI
01:03:22
elements that alert the user that he or she should only use this interface if they are on the system browser. Okay, more questions? Once again, oh, yes.
01:04:03
Well, I can have a secret that is associated to the token agent. However, if it is a static secret, it will not be a secret anymore.
01:04:20
So what I will do is obtain a way of creating a per-device secret which I attach to the user identity when the user authenticates. So the first time that the token agent interacts with the authorization server, it is sending the user credentials.
01:04:42
And I can't validate those credentials. And probably I would ask, are you on a new device? Are you, do you allow the creation of a new device? And if the user allows, which I will never be sure that it did,
01:05:01
I create a new device which is connected to the user. In this case, I didn't have to do that. I just inserted the credentials
01:05:20
and it creates a new identity. What I'll do is to associate the identity of the device to the first identity of a user that uses that device. And then I have a unique identifier and eventually a unique secret for that device. And in further interactions between the token agent
01:05:45
and the authorization server, the device, the token agent will use this specific per-device secret. Yes, yes. I may have a static provisioning using a static secret
01:06:03
which probably will not be secret for a long time. But then I have a per-device provisioning that is connected to the user that first authenticated. Because I don't, I always want to associate a device to a user and don't allow
01:06:23
the unbounded creation of devices. So a device must always be dynamically provisioning, provisioned using or via an authenticated user. And for instance, I may only allow that the user can only provision 20 devices or 50 devices.
01:06:46
Insert a bound on a number of devices that can be provisioned by a user. More questions? No? Once again, thank you.