-
Notifications
You must be signed in to change notification settings - Fork 2
/
openid-connect-backchannel-1_0.xml
1094 lines (989 loc) · 40.2 KB
/
openid-connect-backchannel-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-backchannel-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 Back-Channel Logout 1.0">OpenID Connect
Back-Channel Logout 1.0 - draft 06</title>
<author fullname="Michael B. Jones" initials="M.B." surname="Jones">
<organization abbrev="Microsoft">Microsoft</organization>
<address>
<email>mbj@microsoft.com</email>
<uri>http://self-issued.info/</uri>
</address>
</author>
<author fullname="John Bradley" initials="J." surname="Bradley">
<organization abbrev="Yubico">Yubico</organization>
<address>
<email>ve7jtb@ve7jtb.com</email>
<uri>http://www.thread-safe.com/</uri>
</address>
</author>
<date day="7" month="August" year="2020" />
<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 specification defines a logout mechanism that uses direct back-channel
communication between the OP and RPs being logged out;
this differs from front-channel logout mechanisms,
which communicate logout requests from the OP to RPs via the User Agent.
</t>
</abstract>
</front>
<middle>
<section anchor="Introduction" title="Introduction">
<t>
OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0
<xref target="RFC6749"/>
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 specification defines a logout mechanism that uses direct back-channel
communication between the OP and RPs being logged out;
this differs from front-channel logout mechanisms,
which communicate logout requests from the OP to RPs via the User Agent.
</t>
<t>
An upside of back-channel communication is that it can be more reliable
than communication through the User Agent, since in the front-channel,
the RP's browser session must be active for the communication to succeed.
(If the RP's browser tab was subsequently used to navigate to an unrelated page,
the RP session will be active unless the user uses the back button to return to it.)
Both the <xref target="OpenID.Session">OpenID Connect Session Management 1.0</xref>
and <xref target="OpenID.FrontChannel">OpenID Connect Front-Channel Logout 1.0</xref>
specifications use front-channel communication,
which communicate logout requests from the OP to RPs via the User Agent.
</t>
<t>
A downside of back-channel communication is that the session state maintained between
the OP and RP over the front-channel, such as cookies and HTML5 local storage,
are not available when using back-channel communication.
As a result, all needed state must be explicitly communicated between the parties.
Furthermore, RPs must implement an application-specific method of terminating
RP sessions with the OP upon receiving back-channel logout requests;
this can be more complicated than simply clearing cookies and HTML5 local storage state,
which is often all that has to happen to implement logout in response to
front-channel logout requests.
</t>
<t>
Another significant limitation of back-channel logout is that the RP's
back-channel logout URI must be reachable from all the OPs used.
This means, for instance, that the RP cannot be behind a firewall or NAT
when used with public OPs.
</t>
<t>
The
<xref target="OpenID.RPInitiated">OpenID Connect RP-Initiated Logout 1.0</xref>
specification complements these specifications by defining a mechanism for a Relying Party
to request that an OpenID Provider log out the End-User.
</t>
<t>
This specification can be used separately from or in combination with
OpenID Connect RP-Initiated Logout 1.0,
OpenID Connect Session Management 1.0, and/or
OpenID Connect Front-Channel Logout 1.0.
</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">RFC 2119</xref>.</t>
<t>
In the .txt version of this specification,
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 specification,
values to be taken literally are indicated by
the use of <spanx style="verb">this fixed-width font</spanx>.
</t>
</section>
<section anchor="Terminology" title="Terminology">
<t>
This specification uses the terms
"Authorization Server",
"Client", "Client Identifier", and "Redirection URI"
defined by <xref target="RFC6749">OAuth 2.0</xref>,
the term "User Agent" defined by <xref target="RFC7230">RFC 7230</xref>,
the terms "Session" and "Session ID" defined by
<xref target="OpenID.FrontChannel">OpenID Connect Front-Channel Logout 1.0</xref>
and the terms defined by
<xref target="OpenID.Core">OpenID Connect Core 1.0</xref>
and <xref target="JWT">JSON Web Token (JWT)</xref>.
</t>
<t>
This specification also defines the following term:
<list style="hanging">
<t hangText="Logout Token">
<vspace/>
<xref target="JWT">JSON Web Token (JWT)</xref> similar to an ID Token
that contains Claims about the logout action being requested.
</t>
</list>
</t>
</section>
</section>
<section anchor="Backchannel" title="Back-Channel Logout">
<section anchor="BCSupport" title="Indicating OP Support for Back-Channel Logout">
<t>
If the OpenID Provider supports
<xref target="OpenID.Discovery">OpenID Connect Discovery 1.0</xref>,
it uses this metadata value to advertise its support for back-channel logout:
</t>
<t>
<list style="hanging">
<t hangText="backchannel_logout_supported">
<vspace/>
OPTIONAL.
Boolean value specifying whether the OP supports back-channel logout,
with <spanx style="verb">true</spanx> indicating support.
If omitted, the default value is <spanx style="verb">false</spanx>.
</t>
</list>
</t>
<t>
It SHOULD also register this related metadata value:
</t>
<t>
<list style="hanging">
<t hangText="backchannel_logout_session_supported">
<vspace/>
OPTIONAL.
Boolean value specifying whether the OP can pass
a <spanx style="verb">sid</spanx> (session ID)
Claim in the Logout Token to identify the RP session with the OP.
If supported, the <spanx style="verb">sid</spanx>
Claim is also included in ID Tokens issued by the OP.
If omitted, the default value is <spanx style="verb">false</spanx>.
</t>
</list>
</t>
<t>
The <spanx style="verb">sid</spanx> (session ID) Claim used in ID Tokens and
as a Logout Token parameter has the following definition
(which is identical to the corresponding definition in
<xref target="OpenID.FrontChannel">OpenID Connect Front-Channel Logout 1.0</xref>):
</t>
<t>
<list style="hanging">
<t hangText="sid">
<vspace/>
OPTIONAL.
Session ID - String identifier for a Session.
This represents a Session of a User Agent or device
for a logged-in End-User at an RP.
Different <spanx style="verb">sid</spanx> values are used to identify
distinct sessions at an OP.
The <spanx style="verb">sid</spanx> value need only be unique
in the context of a particular issuer.
Its contents are opaque to the RP.
Its syntax is the same as an OAuth 2.0 Client Identifier.
</t>
</list>
</t>
</section>
<section anchor="BCRegistration" title="Indicating RP Support for Back-Channel Logout">
<t>
Relying Parties supporting back-channel-based logout register a back-channel logout URI
with the OP as part of their client registration.
</t>
<t>
The back-channel logout URI MUST be an absolute URI as defined by
Section 4.3 of <xref target='RFC3986' />.
The back-channel logout URI MAY include an
<spanx style='verb'>application/x-www-form-urlencoded</spanx> formatted
query component, per Section 3.4 of <xref target='RFC3986' />,
which MUST be retained when adding additional query parameters.
The back-channel logout URI MUST NOT include a fragment component.
</t>
<t>
If the RP supports
<xref target="OpenID.Registration">OpenID Connect Dynamic Client Registration 1.0</xref>,
it uses this metadata value to register the back-channel logout URI:
</t>
<t>
<list style="hanging">
<t hangText="backchannel_logout_uri">
<vspace/>
OPTIONAL.
RP URL that will cause the RP to log itself out
when sent a Logout Token by the OP.
This URL SHOULD use the <spanx style="verb">https</spanx> scheme
and MAY contain port, path, and query parameter components;
however, it MAY use the <spanx style="verb">http</spanx> scheme,
provided that the Client Type is <spanx style="verb">confidential</spanx>,
as defined in Section 2.1 of <xref target="RFC6749">OAuth 2.0</xref>, and
provided the OP allows the use of <spanx style="verb">http</spanx> RP URIs.
</t>
</list>
</t>
<t>
It SHOULD also register this related metadata value:
</t>
<t>
<list style="hanging">
<t hangText="backchannel_logout_session_required">
<vspace/>
OPTIONAL.
Boolean value specifying whether the RP requires that
a <spanx style="verb">sid</spanx> (session ID)
Claim be included in the Logout Token to identify the RP session with the OP
when the <spanx style="verb">backchannel_logout_uri</spanx> is used.
If omitted, the default value is <spanx style="verb">false</spanx>.
</t>
</list>
</t>
</section>
<section anchor="Tracking" title="Remembering Logged-In RPs">
<t>
OPs supporting back-channel logout need to keep track of
the set of logged-in RPs so that they know what RPs to contact
at their back-channel logout URIs to cause them to log out.
Some OPs track this state using a "visited sites" cookie.
OPs are encouraged to send logout requests to them in parallel.
</t>
</section>
<section anchor="LogoutToken" title="Logout Token">
<t>
OPs send a JWT similar to an ID Token to RPs called a Logout Token
to request that they log out.
ID Tokens are defined in Section 2 of <xref target="OpenID.Core"/>.
</t>
<t>
The following Claims are used within the Logout Token:
</t>
<t>
<list style="hanging">
<t hangText="iss">
<vspace/>
REQUIRED.
Issuer Identifier, as specified in Section 2 of <xref target="OpenID.Core"/>.
</t>
<t hangText="sub">
<vspace/>
OPTIONAL.
Subject Identifier, as specified in Section 2 of <xref target="OpenID.Core"/>.
</t>
<t hangText="aud">
<vspace/>
REQUIRED.
Audience(s), as specified in Section 2 of <xref target="OpenID.Core"/>.
</t>
<t hangText="iat">
<vspace/>
REQUIRED.
Issued at time, as specified in Section 2 of <xref target="OpenID.Core"/>.
</t>
<t hangText="jti">
<vspace/>
REQUIRED.
Unique identifier for the token, as specified in Section 9 of <xref target="OpenID.Core"/>.
</t>
<t hangText="events">
<vspace/>
REQUIRED.
Claim whose value is a JSON object
containing the member name
<spanx style="verb">http://schemas.openid.net/event/backchannel-logout</spanx>.
This declares that the JWT is a Logout Token.
The corresponding member value MUST be a JSON object and
SHOULD be the empty JSON object <spanx style="verb">{}</spanx>.
</t>
<t hangText="sid">
<vspace/>
OPTIONAL.
Session ID - String identifier for a Session.
This represents a Session of a User Agent or device
for a logged-in End-User at an RP.
Different <spanx style="verb">sid</spanx> values are used to identify
distinct sessions at an OP.
The <spanx style="verb">sid</spanx> value need only be unique
in the context of a particular issuer.
Its contents are opaque to the RP.
Its syntax is the same as an OAuth 2.0 Client Identifier.
</t>
</list>
</t>
<t>
A Logout Token MUST contain either a <spanx style="verb">sub</spanx>
or a <spanx style="verb">sid</spanx> Claim, and MAY contain both.
If a <spanx style="verb">sid</spanx> Claim is not present,
the intent is that all sessions at the RP
for the End-User identified by the <spanx style="verb">iss</spanx>
and <spanx style="verb">sub</spanx> Claims be logged out.
</t>
<t>
The following Claim MUST NOT be used within the Logout Token:
</t>
<t>
<list style="hanging">
<t hangText="nonce">
<vspace/>
PROHIBITED.
A <spanx style="verb">nonce</spanx> Claim MUST NOT be present.
Its use is prohibited to make a Logout Token syntactically invalid
if used in a forged Authentication Response in place of an ID Token.
</t>
</list>
</t>
<t>
Logout Tokens MAY contain other Claims.
Any Claims used that are not understood MUST be ignored.
</t>
<t>
A Logout Token MUST be signed and MAY also be encrypted.
The same keys are used to sign and encrypt Logout Tokens
as are used for ID Tokens.
If the Logout Token is encrypted, it SHOULD replicate the
<spanx style="verb">iss</spanx> (issuer) claim
in the JWT Header Parameters,
as specified in Section 5.3 of <xref target="JWT"/>.
</t>
<t>
NOTE: The Logout Token is compatible with
the Security Event Token (SET) <xref target="RFC8417"/> specification.
</t>
<figure>
<preamble>
A non-normative example JWT Claims Set for a Logout Token follows:
</preamble>
<artwork><![CDATA[
{
"iss": "https://server.example.com",
"sub": "248289761001",
"aud": "s6BhdRkqt3",
"iat": 1471566154,
"jti": "bWJq",
"sid": "08a5019c-17e1-4977-8f42-65a12843ea02",
"events": {
"http://schemas.openid.net/event/backchannel-logout": {}
}
}
]]></artwork>
</figure>
</section>
<section anchor="BCRequest" title="Back-Channel Logout Request">
<t>
The OP uses an HTTP POST to the registered back-channel logout URI
to trigger the logout actions by the RP. The POST body uses the
<spanx style="verb">application/x-www-form-urlencoded</spanx> encoding
and must include a <spanx style="verb">logout_token</spanx> parameter
containing a Logout Token from the OP for the RP identifying the
End-User to be logged out.
</t>
<t>
The POST body MAY contain other values in addition to
<spanx style="verb">logout_token</spanx>.
Values that are not understood by the implementation MUST be ignored.
</t>
<figure>
<preamble>
The following is a non-normative example of such a logout request
(with most of the Logout Token contents omitted for brevity):
</preamble>
<artwork><![CDATA[
POST /backchannel_logout HTTP/1.1
Host: rp.example.org
Content-Type: application/x-www-form-urlencoded
logout_token=eyJhbGci ... .eyJpc3Mi ... .T3BlbklE ...
]]></artwork>
</figure>
</section>
<section anchor="Validation" title="Logout Token Validation">
<t>
Upon receiving a logout request at the back-channel logout URI,
the RP MUST validate the Logout Token as follows:
</t>
<t>
<list style="numbers">
<t>
If the Logout Token is encrypted, decrypt it using the
keys and algorithms that the Client specified during Registration
that the OP was to use to encrypt ID Tokens.
If ID Token encryption was negotiated with the OP at Registration time
and the Logout Token is not encrypted, the RP SHOULD reject it.
</t>
<t>
Validate the Logout Token signature in the same way that
an ID Token signature is validated, with the following refinements.
</t>
<t>
Validate the <spanx style="verb">iss</spanx>,
<spanx style="verb">aud</spanx>,
and <spanx style="verb">iat</spanx>
Claims in the same way they are validated in ID Tokens.
</t>
<t>
Verify that the Logout Token contains a <spanx style="verb">sub</spanx> Claim,
a <spanx style="verb">sid</spanx> Claim, or both.
</t>
<t>
Verify that the Logout Token contains an
<spanx style="verb">events</spanx> Claim
whose value is JSON object containing the member name
<spanx style="verb">http://schemas.openid.net/event/backchannel-logout</spanx>.
</t>
<t>
Verify that the Logout Token does not contain a
<spanx style="verb">nonce</spanx> Claim.
</t>
<t>
Optionally verify that another Logout Token with the same
<spanx style="verb">jti</spanx> value has not been recently received.
</t>
<t>
Optionally verify that the <spanx style="verb">iss</spanx> Logout Token Claim
matches the <spanx style="verb">iss</spanx> Claim in an ID Token issued
for the current session or a recent session of this RP with the OP.
</t>
<t>
Optionally verify that any <spanx style="verb">sub</spanx> Logout Token Claim
matches the <spanx style="verb">sub</spanx> Claim in an ID Token issued
for the current session or a recent session of this RP with the OP.
</t>
<t>
Optionally verify that any <spanx style="verb">sid</spanx> Logout Token Claim
matches the <spanx style="verb">sid</spanx> Claim in an ID Token issued
for the current session or a recent session of this RP with the OP.
</t>
</list>
</t>
<t>
If any of the validation steps fails, reject the Logout Token
and return an HTTP 400 Bad Request error.
Otherwise, proceed to perform the logout actions.
</t>
</section>
<section anchor="BCActions" title="Back-Channel Logout Actions">
<t>
After receiving a valid Logout Token from the OpenID Provider,
the RP locates the session(s) identified by the
<spanx style="verb">iss</spanx> and
<spanx style="verb">sub</spanx> Claims
and/or the <spanx style="verb">sid</spanx> Claim.
The RP then clears any state associated with the identified session(s).
The mechanism by which the RP achieves this is implementation specific.
If the identified End-User is already logged out at the RP when the logout request
is received, the logout is considered to have succeeded.
</t>
<t>
In the case that the RP is also an OP serving as an identity provider
to downstream logged-in sessions, it is desirable for the logout request
to the RP to likewise trigger downstream logout requests.
This is achieved by having the RP/OP send logout requests to its downstream RPs
as part of its logout actions.
</t>
<t>
Refresh tokens issued without the <spanx style="verb">offline_access</spanx> property
to a session being logged out SHOULD be revoked.
Refresh tokens issued with the <spanx style="verb">offline_access</spanx> property
normally SHOULD NOT be revoked.
NOTE: An open issue for the specification is whether to define an additional optional parameter
in the logout token, probably as a value in the event-specific parameters JSON object,
that explicitly signals that <spanx style="verb">offline_access</spanx> refresh tokens
are also to be revoked.
</t>
</section>
<section anchor="BCResponse" title="Back-Channel Logout Response">
<t>
If the logout succeeded, the RP MUST respond with HTTP 200 OK.
If the logout request was invalid, the RP MUST respond with HTTP 400 Bad Request.
If the logout failed, the RP MUST respond with 501 Not Implemented.
If the local logout succeeded but some downstream logouts have failed,
the RP MUST respond with HTTP 504 Gateway Timeout.
</t>
<t>
The RP's response SHOULD include <spanx style="verb">Cache-Control</spanx>
directives keeping the response from being cached to prevent cached responses
from interfering with future logout requests.
It is RECOMMENDED that these directives be used:
</t>
<figure><artwork><![CDATA[
Cache-Control: no-cache, no-store
Pragma: no-cache
]]></artwork></figure>
</section>
</section>
<section anchor="ImplementationConsiderations" title="Implementation Considerations">
<t>
This specification defines features used by both Relying Parties and
OpenID Providers that choose to implement Back-Channel Logout.
All of these Relying Parties and OpenID Providers
MUST implement the features that are listed
in this specification as being "REQUIRED" or are described with a "MUST".
No other implementation considerations for implementations of
Back-Channel Logout are defined by this specification.
</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>
The signed Logout Token is required in the logout request to prevent
denial of service attacks by enabling the RP to verify that
the logout request is coming from a legitimate party.
</t>
<t>
The kinds of Relying Parties that can be logged out by different implementations
will vary. Implementations should make it clear, for instance,
whether they are capable of logging out native applications or only Web RPs.
</t>
<t>
OPs are encouraged to use short expiration times in Logout Tokens,
preferably at most two minutes in the future,
to prevent captured Logout Tokens from being replayable.
</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<section anchor="DynRegRegistration" title="OAuth Dynamic Client Registration Metadata Registration">
<t>
This specification registers the following client metadata definitions
in the IANA "OAuth Dynamic Client Registration Metadata" registry
<xref target="IANA.OAuth.Parameters"/>
established by <xref target="RFC7591"/>:
</t>
<section anchor="DynRegContents" title="Registry Contents">
<t> <?rfc subcompact="yes"?>
<list style="symbols">
<t>
Client Metadata Name: <spanx style="verb">backchannel_logout_uri</spanx>
</t>
<t>
Client Metadata Description:
RP URL that will cause the RP to log itself out
when sent a Logout Token by the OP
</t>
<t>
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
</t>
<t>
Specification Document(s): <xref target="BCRegistration"/> of this specification
</t>
</list>
</t>
<t>
<list style="symbols">
<t>
Client Metadata Name: <spanx style="verb">backchannel_logout_session_required</spanx>
</t>
<t>
Client Metadata Description:
Boolean value specifying whether the RP requires that
a <spanx style="verb">sid</spanx> (session ID)
Claim be included in the Logout Token to identify the RP session with the OP
when the <spanx style="verb">backchannel_logout_uri</spanx> is used
</t>
<t>
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
</t>
<t>
Specification Document(s): <xref target="BCRegistration"/> of this specification
</t>
</list>
</t>
</section>
<?rfc subcompact="no"?>
</section>
<section anchor="ASMetadataRegistry" title="OAuth Authorization Server Metadata Registry">
<t>
This specification registers the following metadata names in the
IANA "OAuth Authorization Server Metadata" registry <xref target="IANA.OAuth.Parameters"/>
established by <xref target="RFC8414"/>.
</t>
<section anchor='MetadataContents' title='Registry Contents'>
<t>
<?rfc subcompact="yes"?>
<list style='symbols'>
<t>
Metadata Name: <spanx style="verb">backchannel_logout_supported</spanx>
</t>
<t>
Metadata Description:
Boolean value specifying whether the OP supports back-channel logout,
with <spanx style="verb">true</spanx> indicating support
</t>
<t>
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
</t>
<t>
Specification Document(s): <xref target="Backchannel"/> of this document
</t>
</list>
</t>
<t>
<list style='symbols'>
<t>
Metadata Name: <spanx style="verb">backchannel_logout_session_supported</spanx>
</t>
<t>
Metadata Description:
Boolean value specifying whether the OP can pass
a <spanx style="verb">sid</spanx> (session ID)
Claim in the Logout Token to identify the RP session with the OP
</t>
<t>
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
</t>
<t>
Specification Document(s): <xref target="Backchannel"/> of this document
</t>
</list>
</t>
</section>
<?rfc subcompact="no"?>
</section>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119"?>
<?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3986"?>
<?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6749"?>
<?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7230"?>
<reference anchor="OpenID.Core" target="http://openid.net/specs/openid-connect-core-1_0.html">
<front>
<title>OpenID Connect Core 1.0</title>
<author fullname="Nat Sakimura" initials="N." surname="Sakimura">
<organization abbrev="NAT.Consulting (was at NRI)">NAT.Consulting</organization>
</author>
<author fullname="John Bradley" initials="J." surname="Bradley">
<organization abbrev="Yubico (was at Ping Identity)">Yubico</organization>
</author>
<author fullname="Michael B. Jones" initials="M.B." surname="Jones">
<organization abbrev="Microsoft">Microsoft</organization>
</author>
<author fullname="Breno de Medeiros" initials="B." surname="de Medeiros">
<organization abbrev="Google">Google</organization>
</author>
<author fullname="Chuck Mortimore" initials="C." surname="Mortimore">
<organization abbrev="VISA (was at Salesforce)">VISA</organization>
</author>
<date day="8" month="November" year="2014"/>
</front>
</reference>
<reference anchor="OpenID.Discovery" target="http://openid.net/specs/openid-connect-discovery-1_0.html">
<front>
<title>OpenID Connect Discovery 1.0</title>
<author fullname="Nat Sakimura" initials="N." surname="Sakimura">
<organization abbrev="NAT.Consulting (was at NRI)">NAT.Consulting</organization>
</author>
<author fullname="John Bradley" initials="J." surname="Bradley">
<organization abbrev="Yubico (was at Ping Identity)">Yubico</organization>
</author>
<author fullname="Michael B. Jones" initials="M.B." surname="Jones">
<organization abbrev="Microsoft">Microsoft</organization>
</author>
<author fullname="Edmund Jay" initials="E." surname="Jay">
<organization abbrev="Illumila">Illumila</organization>
</author>
<date day="8" month="November" year="2014"/>
</front>
</reference>
<reference anchor="OpenID.Registration" target="http://openid.net/specs/openid-connect-registration-1_0.html">
<front>
<title>OpenID Connect Dynamic Client Registration 1.0</title>
<author fullname="Nat Sakimura" initials="N." surname="Sakimura">
<organization abbrev="NAT.Consulting (was at NRI)">NAT.Consulting</organization>
</author>
<author fullname="John Bradley" initials="J." surname="Bradley">
<organization abbrev="Yubico (was at Ping Identity)">Yubico</organization>
</author>
<author fullname="Michael B. Jones" initials="M.B." surname="Jones">
<organization abbrev="Microsoft">Microsoft</organization>
</author>
<date day="8" month="November" year="2014"/>
</front>
</reference>
<reference anchor="OpenID.RPInitiated" target="http://openid.net/specs/openid-connect-rpinitiated-1_0.html">
<front>
<title>OpenID Connect RP-Initiated Logout 1.0</title>
<author fullname="Michael B. Jones" initials="M.B." surname="Jones">
<organization abbrev="Microsoft">Microsoft</organization>
</author>
<author fullname="Breno de Medeiros" initials="B." surname="de Medeiros">
<organization>Google</organization>
</author>
<author fullname="Naveen Agarwal" initials="N." surname="Agarwal">
<organization>Microsoft</organization>
</author>
<author fullname="Nat Sakimura" initials="N." surname="Sakimura">
<organization abbrev="NAT.Consulting">NAT.Consulting</organization>
</author>
<author fullname="John Bradley" initials="J." surname="Bradley">
<organization abbrev="Yubico">Yubico</organization>
</author>
<date day="7" month="August" year="2020" />
</front>
</reference>
<reference anchor="OpenID.FrontChannel" target="http://openid.net/specs/openid-connect-frontchannel-1_0.html">
<front>
<title>OpenID Connect Front-Channel Logout 1.0</title>
<author fullname="Michael B. Jones" initials="M.B." surname="Jones">
<organization abbrev="Microsoft">Microsoft</organization>
</author>
<date day="7" month="August" year="2020" />
</front>
</reference>
<reference anchor="OpenID.Session" target="http://openid.net/specs/openid-connect-session-1_0.html">
<front>
<title>OpenID Connect Session Management 1.0</title>
<author fullname="Breno de Medeiros" initials="B." surname="de Medeiros">
<organization>Google</organization>
</author>
<author fullname="Naveen Agarwal" initials="N." surname="Agarwal">
<organization>Microsoft</organization>
</author>
<author fullname="Nat Sakimura" initials="N." surname="Sakimura">
<organization abbrev="NAT.Consulting">NAT.Consulting</organization>
</author>
<author fullname="John Bradley" initials="J." surname="Bradley">
<organization abbrev="Yubico">Yubico</organization>
</author>
<author fullname="Michael B. Jones" initials="M.B." surname="Jones">
<organization abbrev="Microsoft">Microsoft</organization>
</author>
<date day="7" month="August" year="2020" />
</front>
</reference>
<reference anchor="JWT" target='http://www.rfc-editor.org/info/rfc7519'>
<front>
<title>JSON Web Token (JWT)</title>
<author fullname="Michael B. Jones" initials="M.B." surname="Jones">
<organization>Microsoft</organization>
<address>
<email>mbj@microsoft.com</email>
<uri>http://self-issued.info/</uri>
</address>
</author>
<author fullname="John Bradley" initials="J." surname="Bradley">
<organization abbrev="Ping Identity">Ping Identity</organization>
<address>
<email>ve7jtb@ve7jtb.com</email>
<uri>http://www.thread-safe.com/</uri>
</address>
</author>
<author fullname="Nat Sakimura" initials="N." surname="Sakimura">
<organization abbrev="NRI">Nomura Research Institute</organization>
<address>
<email>n-sakimura@nri.co.jp</email>
<uri>http://nat.sakimura.org/</uri>
</address>
</author>
<date month="May" year="2015"/>
</front>
<seriesInfo name="RFC" value="7519" />
<seriesInfo name="DOI" value="10.17487/RFC7519"/>
</reference>
<reference anchor="IANA.JWT.Claims" target="http://www.iana.org/assignments/jwt">
<front>
<title>JSON Web Token Claims</title>
<author>
<organization>IANA</organization>
</author>
<date/>
</front>
</reference>
<reference anchor="IANA.OAuth.Parameters" target="http://www.iana.org/assignments/oauth-parameters">
<front>
<title>OAuth Parameters</title>
<author>
<organization>IANA</organization>
</author>
<date/>
</front>
</reference>
</references>
<references title="Informative References">
<?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7591"?>
<?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8414"?>
<?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8417"?>
</references>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>
The OpenID Community would like to thank the following people for
their contributions to this specification:
</t>
<t>
<list style="empty">
<t>John Bradley (ve7jtb@ve7jtb.com), Yubico</t>
<t>Brian Campbell (bcampbell@pingidentity.com), Ping Identity</t>
<t>Vladimir Dzhuvinov (vladimir@connect2id.com), Connect2id</t>
<t>Pedro Felix (pmhsfelix@gmail.com), individual</t>
<t>Joseph Heenan (joseph@authlete.com), Authlete</t>
<t>Phil Hunt (phil.hunt@oracle.com), Oracle</t>
<t>Michael B. Jones (mbj@microsoft.com), Microsoft</t>
<t>Todd Lainhart (lainhart@us.ibm.com), IBM</t>
<t>Torsten Lodderstedt (torsten@lodderstedt.net), yes.com</t>
<t>Nat Sakimura (nat@nat.consulting), NAT.Consulting</t>
<t>Filip Skokan (panva.ip@gmail.com), Auth0</t>
<t>Hans Zandbelt (hans.zandbelt@zmartzone.eu), ZmartZone</t>
</list>
</t>
</section>
<section anchor="Notices" title="Notices">
<t>Copyright (c) 2020 The OpenID Foundation.</t>
<t>The OpenID Foundation (OIDF) grants to any Contributor, developer,
implementer, or other interested party a non-exclusive, royalty free,
worldwide copyright license to reproduce, prepare derivative works from,
distribute, perform and display, this Implementers Draft or Final
Specification solely for the purposes of (i) developing specifications,
and (ii) implementing Implementers Drafts and Final Specifications based
on such documents, provided that attribution be made to the OIDF as the
source of the material, but that such attribution does not indicate an
endorsement by the OIDF.</t>
<t>The technology described in this specification was made available
from contributions from various sources, including members of the OpenID
Foundation and others. Although the OpenID Foundation has taken steps to
help ensure that the technology is available for distribution, it takes
no position regarding the validity or scope of any intellectual property
or other rights that might be claimed to pertain to the implementation
or use of the technology described in this specification or the extent
to which any license under such rights might or might not be available;
neither does it represent that it has made any independent effort to
identify any such rights. The OpenID Foundation and the contributors to
this specification make no (and hereby expressly disclaim any)
warranties (express, implied, or otherwise), including implied
warranties of merchantability, non-infringement, fitness for a
particular purpose, or title, related to this specification, and the
entire risk as to implementing this specification is assumed by the
implementer. The OpenID Intellectual Property Rights policy requires
contributors to offer a patent promise not to assert certain patent
claims against other contributors and against implementers. The OpenID
Foundation invites any interested party to bring to its attention any
copyrights, patents, patent applications, or other proprietary rights
that may cover technology that may be required to practice this
specification.</t>
</section>
<section anchor="History" title="Document History">
<t>[[ To be removed from the final specification ]]</t>
<t>
-06
<list style="symbols">
<t>
Fixed #1030 - Specify the use of HTTPS URIs.
</t>
<t>
Fixed #1031 - Specify <spanx style="verb">sid</spanx> ID Token claim for use in Back-Channel Logout.
</t>
<t>
Fixed #1176 - Verify that the <spanx style="verb">sid</spanx> Logout Token claim matches this claim in an ID Token.
</t>
<t>
Added Implementation Considerations section.
</t>
<t>
Fixed #1049 - Include a reference to the OP when the Logout Token is encrypted.
</t>
</list>
</t>