-
Notifications
You must be signed in to change notification settings - Fork 1
/
Copy pathopenid-connect-implicit-1_0.xml
executable file
·3516 lines (3145 loc) · 147 KB
/
openid-connect-implicit-1_0.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<?xml version="1.0" encoding="US-ASCII"?>
<?xml-stylesheet type='text/xsl' href='http://xml2rfc.tools.ietf.org/authoring/rfc2629.xslt' ?>
<!DOCTYPE rfc PUBLIC "-//IETF//DTD RFC 2629//EN"
"http://xml2rfc.tools.ietf.org/authoring/rfc2629.dtd">
<!--
NOTE: This XML file is input used to produce the authoritative copy of an
OpenID Foundation specification. The authoritative copy is the HTML output.
This XML source file is not authoritative. The statement ipr="none" is
present only to satisfy the document compilation tool and is not indicative
of the IPR status of this specification. The IPR for this specification is
described in the "Notices" section. This is a public OpenID Foundation
document and not a private document, as the private="..." declaration could
be taken to indicate.
-->
<rfc category="std" docName="openid-connect-implicit-1_0" ipr="none">
<?rfc toc="yes" ?>
<?rfc tocdepth="5" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc strict="yes" ?>
<?rfc iprnotified="no" ?>
<?rfc private="Draft" ?>
<front>
<title abbrev="OpenID Connect Implicit Client Guide 1.0">OpenID Connect
Implicit Client Implementer's Guide 1.0 - draft 20</title>
<author fullname="Nat Sakimura" initials="N." surname="Sakimura">
<organization abbrev="NRI">Nomura Research Institute, Ltd.</organization>
<address>
<email>[email protected]</email>
<uri>http://nat.sakimura.org/</uri>
</address>
</author>
<author fullname="John Bradley" initials="J." surname="Bradley">
<organization abbrev="Ping Identity">Ping Identity</organization>
<address>
<email>[email protected]</email>
<uri>http://www.thread-safe.com/</uri>
</address>
</author>
<author fullname="Michael B. Jones" initials="M.B." surname="Jones">
<organization abbrev="Microsoft">Microsoft</organization>
<address>
<email>[email protected]</email>
<uri>http://self-issued.info/</uri>
</address>
</author>
<author fullname="Breno de Medeiros" initials="B." surname="de Medeiros">
<organization abbrev="Google">Google</organization>
<address>
<email>[email protected]</email>
<uri>http://stackoverflow.com/users/311376/breno</uri>
</address>
</author>
<author fullname="Chuck Mortimore" initials="C." surname="Mortimore">
<organization abbrev="Salesforce">Salesforce</organization>
<address>
<email>[email protected]</email>
<uri>https://twitter.com/cmort</uri>
</address>
</author>
<date day="3" month="August" year="2015" />
<workgroup>OpenID Connect Working Group</workgroup>
<abstract>
<t>OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0
protocol. It enables Clients to verify the identity of the End-User based
on the authentication performed by an Authorization Server, as well as to
obtain basic profile information about the End-User in an interoperable and
REST-like manner.</t>
<t>
This OpenID Connect Implicit Client Implementer's Guide 1.0 contains a subset of the
OpenID Connect Core 1.0 specification
that is designed to be easy to read and implement for basic
Web-based Relying Parties using the
OAuth 2.0 Implicit Flow.
This document intentionally duplicates content from the Core
specification to provide a self-contained implementer's guide for basic
Web-based Relying Parties using the
OAuth Implicit Flow.
</t>
<t>
OpenID Providers and non-Web-based applications
should instead consult the Core specification.
</t>
</abstract>
</front>
<middle>
<section anchor="Introduction" title="Introduction">
<t>
This OpenID Connect Implicit Client Implementer's Guide 1.0 contains a subset of the
<xref target="OpenID.Core">OpenID Connect Core 1.0</xref> specification
that is designed to be easy to read and implement for basic
Web-based Relying Parties using the
OAuth <xref target="RFC6749"/> Implicit Flow.
This document intentionally duplicates content from the Core
specification to provide a self-contained implementer's guide for basic
Web-based Relying Parties using the
OAuth Implicit Flow.
Should there be any conflicts between the contents of this implementer's guide
and the OpenID Connect Core specification, the latter takes precedence.
</t>
<t>
See the
<xref target="OpenID.Basic">OpenID Connect Basic Client Implementer's Guide 1.0</xref>
for a related guide for basic
Web-based Relying Parties using the
OAuth <spanx style="verb">authorization_code</spanx> grant type.
OpenID Providers and non-Web-based applications
should instead consult the Core specification.
This guide omits implementation and security
considerations for OpenID Providers and non-Web-based applications.
</t>
<t>
As background,
the <xref target="RFC6749">OAuth 2.0 Authorization Framework</xref>
and <xref target="RFC6750">OAuth 2.0 Bearer Token Usage</xref>
specifications provide a general framework for third-party applications
to obtain and use limited access to HTTP resources. They define
mechanisms to obtain and use Access Tokens to access resources but
do not define standard methods to provide identity information.
Notably, without profiling OAuth 2.0, it is incapable of
providing information about the authentication of an End-User.
Readers are expected to be familiar with these specifications.
</t>
<t>
OpenID Connect implements authentication as an extension to the
OAuth 2.0 authorization process.
Use of this extension is requested by Clients by including
the <spanx style="verb">openid</spanx> scope value
in the Authorization Request.
An Authorization Request using these extensions
is called an Authentication Request.
</t>
<t>
Information about the authentication performed is returned
in a <xref target="JWT">JSON Web Token (JWT)</xref>
called an ID Token (see <xref target="IDToken"/>).
OAuth 2.0 Authentication Servers implementing OpenID Connect
are also referred to as OpenID Providers (OPs).
OAuth 2.0 Clients using OpenID Connect
are also referred to as Relying Parties (RPs).
</t>
<t>
This document assumes that the Relying Party has already obtained
configuration information about the OpenID Provider, including its
Authorization Endpoint location.
This information is normally obtained via Discovery,
as described in <xref target="OpenID.Discovery">OpenID Connect Discovery 1.0</xref>,
or may be obtained via other mechanisms.
</t>
<t>
Likewise, this document assumes that the Relying Party has already obtained
sufficient credentials and provided information needed to use the OpenID Provider.
This is normally done via Dynamic Registration,
as described in
<xref target="OpenID.Registration">OpenID Connect Dynamic Client Registration 1.0</xref>,
or may be obtained via other mechanisms.
</t>
<section anchor="rnc" title="Requirements Notation and Conventions">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119"/>.</t>
<t>
In the .txt version of this document,
values are quoted to indicate that they are to be taken literally.
When using these values in protocol messages,
the quotes MUST NOT be used as part of the value.
In the HTML version of this document,
values to be taken literally are indicated by
the use of <spanx style="verb">this fixed-width font</spanx>.
</t>
<t>
All uses of <xref target="JWS">JSON Web Signature (JWS)</xref>
data structures in this document utilize
the JWS Compact Serialization;
the JWS JSON Serialization is not used.
</t>
<t>
When the RFC 2119 language applies to the behavior of OpenID Providers,
it is in this document for explanatory value to help Client
implementers understand the expected behavior of OpenID Providers.
</t>
</section>
<section anchor="Terminology" title="Terminology">
<t>
This document uses the terms "Access Token", "Authorization Code",
"Authorization Endpoint", "Authorization Grant", "Authorization Server",
"Client", "Client Identifier", "Client Secret",
"Protected Resource", "Redirection URI", "Refresh Token",
"Resource Owner", "Resource Server", "Response Type", and "Token Endpoint"
defined by <xref target="RFC6749">OAuth 2.0</xref>,
the terms "Claim Name", "Claim Value", "JSON Web Token (JWT)",
and "JWT Claims Set"
defined by <xref target="JWT">JSON Web Token (JWT)</xref>,
the terms "Header Parameter" and "JOSE Header"
defined by <xref target="JWS">JSON Web Signature (JWS)</xref>,
and the term "User Agent" defined by <xref target="RFC7230">RFC 7230</xref>.
</t>
<t>
This document also defines the following terms:
<list style="hanging">
<t hangText="Authentication">
<vspace/>
Process used to achieve sufficient confidence in the binding
between the Entity and the presented Identity.
</t>
<t hangText="Authentication Request">
<vspace/>
OAuth 2.0 Authorization Request using extension parameters and scopes
defined by OpenID Connect to request that the End-User be authenticated
by the Authorization Server, which is an OpenID Connect Provider,
to the Client, which is an OpenID Connect Relying Party.
</t>
<t hangText="Claim">
<vspace/>
Piece of information asserted about an Entity.
</t>
<t hangText="Claims Provider">
<vspace/>
Server that can return Claims about an Entity.
</t>
<t hangText="End-User">
<vspace/>
Human participant.
</t>
<t hangText="Entity">
<vspace/>
Something that has a separate and distinct existence and that can be
identified in a context. An End-User is one example of an Entity.
</t>
<t hangText="ID Token">
<vspace/>
<xref target="JWT">JSON Web Token (JWT)</xref> that contains Claims about the Authentication event.
It MAY contain other Claims.
</t>
<t hangText="Identifier">
<vspace/>
Value that uniquely characterizes an Entity in a specific context.
</t>
<t hangText="Issuer">
<vspace/>
Entity that issues a set of Claims.
</t>
<t hangText="Issuer Identifier">
<vspace/>
Verifiable Identifier for an Issuer.
An Issuer Identifier is a case-sensitive URL
using the <spanx style="verb">https</spanx> scheme that
contains scheme, host, and optionally, port number and path
components and no query or fragment components.
</t>
<t hangText="OpenID Provider (OP)">
<vspace/>
OAuth 2.0 Authorization Server that is capable of
Authenticating the End-User and
providing Claims to a Relying Party
about the Authentication event and the End-User.
</t>
<t hangText="Pairwise Pseudonymous Identifier (PPID)">
<vspace/>
Identifier that identifies the Entity to a Relying Party that cannot be correlated
with the Entity's PPID at another Relying Party.
</t>
<t hangText="Personally Identifiable Information (PII)">
<vspace/>
Information that (a) can be used to identify the natural person
to whom such information relates, or
(b) is or might be directly or indirectly linked to a
natural person to whom such information relates.
</t>
<t hangText="Relying Party (RP)">
<vspace/>
OAuth 2.0 Client application requiring End-User Authentication
and Claims from an OpenID Provider.
</t>
<t hangText="Self-Issued OpenID Provider">
<vspace/>
Personal, self-hosted OpenID Provider that issues self-signed ID Tokens.
</t>
<t hangText="Subject Identifier">
<vspace/>
Locally unique and never
reassigned identifier within the Issuer for the End-User,
which is intended to be consumed by the Client.
</t>
<t hangText="UserInfo Endpoint">
<vspace/>
Protected Resource that, when presented with an Access Token by the Client,
returns authorized information about the End-User represented by the corresponding
Authorization Grant.
</t>
<t hangText="Validation">
<vspace/>
Process intended to establish the soundness or correctness of a construct.
</t>
<t hangText="Verification">
<vspace/>
Process intended to test or prove the truth or accuracy of a fact or value.
</t>
<t hangText="Voluntary Claim">
<vspace/>
Claim specified by the Client as being useful but not Essential
for the specific task requested by the End-User.
</t>
</list>
</t>
<t>
IMPORTANT NOTE TO READERS: The terminology definitions in
this section are a normative portion of this document,
imposing requirements upon implementations. All the
capitalized words in the text of this document, such as
"Issuer Identifier", reference these defined terms.
Whenever the reader encounters them, their definitions
found in this section must be followed.
</t>
</section>
<section anchor="Overview" title="Overview">
<t>The OpenID Connect protocol, in abstract, follows the following
steps.</t>
<t>
<list style="numbers">
<t>The RP (Client) sends a request to the OpenID Provider (OP).</t>
<t>The OP authenticates the End-User and obtains authorization.</t>
<t>The OP responds with an ID Token and usually an Access Token.</t>
<t>The RP can send a request with the Access Token to the UserInfo Endpoint.</t>
<t>The UserInfo Endpoint returns Claims about the End-User.</t>
</list>
</t>
<figure>
<preamble>
These steps are illustrated in the following diagram:
</preamble>
<artwork><![CDATA[
+--------+ +--------+
| | | |
| |---------(1) AuthN Request-------->| |
| | | |
| | +--------+ | |
| | | | | |
| | | End- |<--(2) AuthN & AuthZ-->| |
| | | User | | |
| RP | | | | OP |
| | +--------+ | |
| | | |
| |<--------(3) AuthN Response--------| |
| | | |
| |---------(4) UserInfo Request----->| |
| | | |
| |<--------(5) UserInfo Response-----| |
| | | |
+--------+ +--------+
]]></artwork>
</figure>
</section>
</section>
<section anchor="ProtocolElements" title="Protocol Elements">
<t>
Authentication Requests can follow one of three paths:
the Authorization Code Flow,
the Implicit Flow, or
the Hybrid Flow.
The Authorization Code Flow is
intended for Clients that can securely maintain a Client Secret between
themselves and the Authorization Server, whereas the Implicit Flow is
intended for Clients that cannot.
However, the Authorization Code flow is sometimes also used by Native applications
and other Clients in order to be able to obtain a Refresh Token,
even when they cannot ensure the secrecy of the Client Secret value.
The Hybrid Flow combines aspects of the Authorization Code Flow
and the Implicit Flow.
It enables Clients to obtain an ID Token optionally an Access Token with only
one round trip to the Authorization Server, possibly minimizing latency,
while still enabling Clients to later get tokens from the Token Endpoint
-- especially a Refresh Token.
</t>
<t>
This document only provides information that is sufficient for
basic Clients using the Implicit Flow.
</t>
<section anchor="ImplicitFlow" title="Implicit Flow">
<t>The Implicit Flow consists of the following steps:</t>
<t>
<list style="numbers">
<t>Client prepares an Authentication Request containing the desired
request parameters.</t>
<t>Client sends the request to the Authorization Server.</t>
<t>Authorization Server authenticates the End-User.</t>
<t>Authorization Server obtains End-User Consent/Authorization.</t>
<t>Authorization Server sends the End-User back to the Client with
an ID Token and, if requested, an Access Token.</t>
<t>Client validates the tokens and retrieves the End-User's
Subject Identifier.</t>
</list>
</t>
<section anchor="AuthenticationRequest" title="Client Prepares Authentication Request">
<t>
When the RP wishes to Authenticate the End-User
or determine whether the End-User is already Authenticated,
the Client prepares an Authentication Request
to be sent to the Authorization Endpoint.
</t>
<t>
Communication with the Authorization Endpoint MUST utilize TLS.
See <xref target="TLSRequirements"/> for more information on using TLS.
</t>
<t>Clients MAY construct the request using the HTTP
<spanx style="verb">GET</spanx> or the HTTP
<spanx style="verb">POST</spanx> method as defined in
<xref target="RFC7231">RFC 7231</xref>.</t>
<t>If using the HTTP <spanx style="verb">GET</spanx> method, the
parameters are serialized using
the Query String Serialization, per <xref target="QuerySerialization"/>.
If using the HTTP
<spanx style="verb">POST</spanx> method, the request parameters are
added to the HTTP request entity-body using the
<spanx style="verb">application/x-www-form-urlencoded</spanx> format
as defined by <xref target="W3C.REC-html401-19991224"/>.</t>
<figure>
<preamble>The following is a non-normative example of an
Authentication Request URL
(with line wraps within values for display purposes only):</preamble>
<artwork><![CDATA[
https://server.example.com/authorize?
response_type=id_token%20token
&client_id=s6BhdRkqt3
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
&scope=openid%20profile
&state=af0ifjsldkj
&nonce=n-0S6_WzA2Mj
]]></artwork>
</figure>
<section anchor="RequestParameters" title="Request Parameters">
<t>
This subset of
OpenID Connect uses the following OAuth 2.0 request parameters:
</t>
<t>
<list style="hanging">
<t hangText="response_type">
<vspace/>
REQUIRED.
This value consists of <spanx style="verb">id_token</spanx> and
<spanx style="verb">token</spanx>, as a space-delimited list.
This requests that both an Access Token and an ID Token be returned
from the Authorization Endpoint, as specified in
<xref target="OAuth.Responses">OAuth 2.0 Multiple Response Type Encoding Practices</xref>.
</t>
<t hangText="client_id">
<vspace/>
REQUIRED.
OAuth 2.0 Client Identifier
valid at the Authorization Server.
</t>
<t hangText="scope">
<vspace/>
REQUIRED.
OpenID Connect requests MUST contain the <spanx style="verb">openid</spanx> scope value.
OPTIONAL scope values of
<spanx style="verb">profile</spanx>,
<spanx style="verb">email</spanx>,
<spanx style="verb">address</spanx>,
<spanx style="verb">phone</spanx>,
and <spanx style="verb">offline_access</spanx>
are also defined.
See <xref target="Scopes"/> for more about the scope values defined by this document.
</t>
<t hangText="redirect_uri">
<vspace/>
REQUIRED.
Redirection URI to which the response will be sent.
This URI MUST exactly match one of the Redirection URI values
for the Client pre-registered at the OpenID Provider,
with the matching performed as described in
Section 6.2.1 of <xref target="RFC3986"/> (Simple String Comparison).
The Redirection URI
MUST NOT use the <spanx style="verb">http</spanx> scheme
unless the Client is a native application, in which case it MAY
use the <spanx style="verb">http:</spanx> scheme with
<spanx style="verb">localhost</spanx> as the hostname.
</t>
<t hangText="state">
<vspace/>
RECOMMENDED.
Opaque value used
to maintain state between the request and the callback.
Typically, Cross-Site Request Forgery (CSRF, XSRF)
mitigation is done by cryptographically binding the value of
this parameter with a browser cookie.
</t>
</list>
</t>
<t>
This document also defines the following request parameters:
</t>
<t>
<list style="hanging">
<t hangText="nonce">
<vspace/>
REQUIRED.
String value used to associate a Client session
with an ID Token, and to mitigate replay attacks.
The value is passed through unmodified from the Authentication Request to the ID Token.
Sufficient entropy MUST be present in the
<spanx style="verb">nonce</spanx> values used to prevent
attackers from guessing values.
One method to achieve this is to store a cryptographically random value
in HTML5 local storage and use a cryptographic hash of the value
as the <spanx style="verb">nonce</spanx> parameter.
In that case, the <spanx style="verb">nonce</spanx> in the returned
ID Token is compared to the hash of the value in local storage
to detect ID Token replay by third parties.
</t>
<t hangText="display">
<vspace/>
OPTIONAL.
ASCII <xref target="RFC20"/> string value that specifies
how the Authorization Server displays the authentication and
consent user interface pages to the End-User.
The defined values are:
<list style="hanging">
<t hangText="page">
<vspace/>
The Authorization Server SHOULD display the
authentication and consent UI consistent with a full User Agent page
view. If the display parameter is not specified, this is the
default display mode.
</t>
<t hangText="popup">
<vspace/>
The Authorization Server SHOULD display the
authentication and consent UI consistent with a popup User Agent
window.
The popup User Agent window should be of an appropriate size
for a login-focused dialog and should not obscure
the entire window that it is popping up over.
</t>
<t hangText="touch">
<vspace/>
The Authorization Server SHOULD display the
authentication and consent UI consistent with a device that
leverages a touch interface.
</t>
<t hangText="wap">
<vspace/>
The Authorization Server SHOULD display the
authentication and consent UI consistent with a "feature phone"
type display.
</t>
</list>
The Authorization Server MAY also attempt to detect the capabilities
of the User Agent and present an appropriate display.
</t>
<t hangText="prompt">
<vspace/>
OPTIONAL.
Space-delimited, case-sensitive list of ASCII string values
that specifies whether the Authorization Server prompts
the End-User for reauthentication and consent.
The defined values are:
<list style="hanging">
<t hangText="none">
<vspace/>
The Authorization Server
MUST NOT display any authentication or consent
user interface pages.
An error is returned
if an End-User
is not already authenticated or the Client does not have
pre-configured consent for the requested
Claims or does not fulfill other conditions for processing the request.
The error code will typically be
<spanx style="verb">login_required</spanx>,
<spanx style="verb">interaction_required</spanx>.
This can be used as a
method to check for existing authentication and/or consent.
</t>
<t hangText="login">
<vspace/>
The Authorization Server SHOULD prompt the
End-User for reauthentication.
If it cannot reauthenticate the End-User, it MUST return an error,
typically <spanx style="verb">login_required</spanx>.
</t>
<t hangText="consent">
<vspace/>
The Authorization Server SHOULD prompt the End-User for consent
before returning information to the Client.
If it cannot obtain consent, it MUST return an error,
typically <spanx style="verb">consent_required</spanx>.
</t>
<t hangText="select_account">
<vspace/>
The Authorization Server SHOULD
prompt the End-User to select a user account. This enables
an End-User who has multiple accounts at the Authorization Server
to select amongst the multiple accounts that they might have
current sessions for.
If it cannot obtain an account selection choice made by the End-User,
it MUST return an error,
typically <spanx style="verb">account_selection_required</spanx>.
</t>
</list>
The <spanx style="verb">prompt</spanx> parameter
can be used by the Client to make sure that the End-User is
still present for the current session or to bring attention to the
request. If this parameter contains <spanx style="verb">none</spanx>
with any other value, an
error is returned.
</t>
<t hangText="max_age">
<vspace/>
OPTIONAL.
Maximum Authentication Age.
Specifies the allowable elapsed time in seconds
since the last time the End-User was actively
authenticated by the OP. If the elapsed time is greater than
this value, the OP MUST attempt to actively
re-authenticate the End-User.
When <spanx style="verb">max_age</spanx> is used, the ID Token returned
MUST include an <spanx style="verb">auth_time</spanx> Claim Value.
</t>
<t hangText="ui_locales">
<vspace/>
OPTIONAL.
End-User's preferred languages and scripts for the user interface,
represented as a space-separated list of
<xref target="RFC5646">BCP47</xref> language tag values,
ordered by preference.
For instance, the value "fr-CA fr en" represents a preference
for French as spoken in Canada,
then French (without a region designation),
followed by English (without a region designation).
An error SHOULD NOT result if some or all of the requested locales
are not supported by the OpenID Provider.
</t>
<t hangText="claims_locales">
<vspace/>
OPTIONAL.
End-User's preferred languages and scripts for Claims being returned,
represented as a space-separated list of
<xref target="RFC5646">BCP47</xref> language tag values,
ordered by preference.
An error SHOULD NOT result if some or all of the requested locales
are not supported by the OpenID Provider.
</t>
<t hangText="id_token_hint">
<vspace/>
OPTIONAL.
ID Token previously issued by the Authorization Server
being passed as a hint about the End-User's current or past
authenticated session with the Client.
If the End-User identified by the ID Token is logged in or is logged in by the request,
then the Authorization Server returns a positive response;
otherwise, it SHOULD return
an error.
When possible, an <spanx style="verb">id_token_hint</spanx>
SHOULD be present when <spanx style="verb">prompt=none</spanx> is used
and an <spanx style="verb">invalid_request</spanx> error
MAY be returned if it is not;
however, the server SHOULD respond successfully when possible,
even if it is not present.
The Authorization Server need not be listed as an
audience of the ID Token when it is used as an
<spanx style="verb">id_token_hint</spanx> value.
</t>
<t hangText="login_hint">
<vspace/>
OPTIONAL.
Hint to the Authorization Server
about the login identifier the End-User might use to log in (if necessary).
This hint can be used by an RP if it first asks the End-User for their e-mail
address (or other identifier) and then wants to pass that value as a hint
to the discovered authorization service.
It is RECOMMENDED that the hint value match the value used for discovery.
This value MAY also be a phone number in the format specified for the
<spanx style="verb">phone_number</spanx> Claim.
The use of this parameter is left to the OP's discretion.
</t>
<t hangText="acr_values">
<vspace/>
OPTIONAL.
Requested Authentication Context Class Reference values.
Space-separated string that specifies the <spanx style="verb">acr</spanx>
values that the Authorization Server is being requested to use
for processing this authentication request,
with the values appearing in order of preference.
The Authentication Context Class satisfied by the authentication
performed is returned as the <spanx style="verb">acr</spanx> Claim Value,
as specified in <xref target="IDToken"/>.
The <spanx style="verb">acr</spanx> Claim is requested as
a Voluntary Claim by this parameter.
</t>
<t hangText="registration">
<vspace/>
OPTIONAL.
This parameter is used by the Client to provide information about itself
to a Self-Issued OP that would normally be provided to an OP during
Dynamic Client Registration,
as specified in <xref target="RegistrationParameter"/>.
</t>
</list>
</t>
</section>
</section>
<section anchor="ImplicitRequest"
title="Client Sends Request to Authorization Server">
<t>Having constructed the Authentication Request, the Client sends it
to the Authorization Endpoint using HTTPS.</t>
<figure>
<preamble>
The following is a non-normative example
HTTP 302 redirect response by the Client, which triggers
the User Agent to make an Authentication Request
to the Authorization Endpoint
(with line wraps within values for display purposes only):
</preamble>
<artwork><![CDATA[
HTTP/1.1 302 Found
Location: https://server.example.com/authorize?
response_type=id_token%20token
&client_id=s6BhdRkqt3
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
&scope=openid%20profile
&state=af0ifjsldkj
&nonce=n-0S6_WzA2Mj
]]></artwork>
</figure>
<figure>
<preamble>
The following is the non-normative example request
that would be sent by the User Agent to the Authorization Server
in response to the HTTP 302 redirect response by the Client above
(with line wraps within values for display purposes only):
</preamble>
<artwork><![CDATA[
GET /authorize?
response_type=id_token%20token
&client_id=s6BhdRkqt3
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
&scope=openid%20profile
&state=af0ifjsldkj
&nonce=n-0S6_WzA2Mj HTTP/1.1
Host: server.example.com
]]></artwork>
</figure>
</section>
<section anchor="Authenticates" title="Authorization Server Authenticates End-User">
<t>
The Authorization Server logs in the End-User or verifies whether
the End-User is logged in, depending upon the request parameter values used.
If interaction with the End-User occurs over an HTTP channel,
it MUST use TLS, as per <xref target="TLSRequirements"/>.
The exact authentication methods used are out of scope for this document.
</t>
</section>
<section anchor="Consent" title="Authorization Server Obtains End-User Consent/Authorization">
<t>The Authorization Server obtains an authorization decision
for the requested Claims. This can done by presenting the End-User
with a dialogue that enables the End-User to recognize what is being
consenting to and grant consent or by establishing consent via
other means (for example, via previous administrative consent).</t>
<t>
The <spanx style="verb">openid</spanx> scope value declares
that this OAuth 2.0 request is an OpenID Connect request.
Use of all other scope values is OPTIONAL.
</t>
</section>
<section anchor="ImplicitResponse"
title="Authorization Server Sends End-User Back to Client">
<t>Once the authorization is determined, the Authorization Server
returns a successful response or an error response.</t>
<section anchor="ImplicitOK" title="End-User Grants Authorization">
<t>If the End-User grants the access request, the
Authorization Server issues an Access Token and delivers it to the
Client by adding the following parameters to the fragment component
of the Redirection URI using the
<spanx style="verb">application/x-www-form-urlencoded</spanx>
format as defined in Section 4.2.2 of
<xref target="RFC6749">OAuth 2.0</xref> and
<xref target="OAuth.Responses">OAuth 2.0 Multiple Response Type Encoding Practices</xref>.</t>
<t>In the Implicit Flow, the entire response is returned in the
fragment component of the Redirection URI, as defined in 4.2.2 of
<xref target="RFC6749">OAuth 2.0</xref>.</t>
<t>
<list style="hanging">
<t hangText="access_token">
<vspace/>
REQUIRED.
Access Token for the
UserInfo Endpoint.
</t>
<t hangText="token_type">
<vspace/>
REQUIRED.
OAuth 2.0 Token Type value.
The value MUST be <spanx style="verb">Bearer</spanx>, as specified in
<xref target="RFC6750">OAuth 2.0 Bearer Token Usage</xref>,
for Clients using this subset.
</t>
<t hangText="id_token">
<vspace/>
REQUIRED.
ID Token.
</t>
<t hangText="state">
<vspace/>
OAuth 2.0 state value.
REQUIRED if the
<spanx style="verb">state</spanx> parameter is present in the
Authorization Request. Clients MUST verify that the
<spanx style="verb">state</spanx> value is equal to the
value of <spanx style="verb">state</spanx> parameter in the
Authorization Request.
</t>
<t hangText="expires_in">
<vspace/>
OPTIONAL.
Expiration time of the Access Token in seconds
since the response was generated.
</t>
</list>
</t>
<t>The Client can then use the Access Token to access protected
resources at Resource Servers.</t>
<figure>
<preamble>The following is a non-normative example
(with line wraps for the display purposes only):</preamble>
<artwork><![CDATA[
HTTP/1.1 302 Found
Location: https://client.example.org/cb#
access_token=SlAV32hkKG
&token_type=bearer
&id_token=eyJ0 ... NiJ9.eyJ1c ... I6IjIifX0.DeWt4Qu ... ZXso
&expires_in=3600
&state=af0ifjsldkj
]]></artwork>
</figure>
</section>
<section anchor="ImplicitAuthzError"
title="End-User Denies Authorization or Invalid Request">
<t>
If the End-User denies the authorization or the End-User authentication
fails, the Authorization Server MUST return the error
Authorization Response as defined in 4.2.2.1 of
<xref target="RFC6749">OAuth 2.0</xref>.
(HTTP errors unrelated to RFC 6749 are returned to the User Agent using the
appropriate HTTP status code.)
</t>
</section>
<section anchor="ImplicitCallback"
title="Redirect URI Fragment Handling">
<t>
Since response parameters are returned in the Redirection URI fragment value,
the Client needs to have the User Agent parse the fragment encoded values
and pass them to on to the Client's processing logic for consumption.
User Agents that have direct access to cryptographic APIs may be able to be
self-contained, for instance, with all Client code being written in JavaScript.
</t>
<t>
However, if the Client does not run entirely in the User Agent,
one way to achieve this
is to post them to a Web Server Client for validation.
</t>
<t>The following is an example of a JavaScript file that a Client might host at its
<spanx style="verb">redirect_uri</spanx>. This is loaded by the redirect from
the Authorization Server. The fragment component is parsed and then sent by <spanx style="verb">POST</spanx> to a URI
that will validate and use the information received.</t>
<figure>
<preamble>Following is a non-normative example of a
Redirect URI response:</preamble>
<artwork><![CDATA[
GET /cb HTTP/1.1
Host: client.example.org
HTTP/1.1 200 OK
Content-Type: text/html
<script type="text/javascript">
// First, parse the query string
var params = {}, postBody = location.hash.substring(1),
regex = /([^&=]+)=([^&]*)/g, m;
while (m = regex.exec(postBody)) {
params[decodeURIComponent(m[1])] = decodeURIComponent(m[2]);
}
// And send the token over to the server
var req = new XMLHttpRequest();
// using POST so query isn't logged
req.open('POST', 'https://' + window.location.host +
'/catch_response', true);
req.setRequestHeader('Content-Type',
'application/x-www-form-urlencoded');
req.onreadystatechange = function (e) {
if (req.readyState == 4) {