<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta content="Common,Latin" name="scripts">
<meta content="initial-scale=1.0" name="viewport">
<title>International Government Assurance Profile (iGov) for OAuth 2.0 - draft 07</title>
<meta content="Kelley Burgin" name="author">
<meta content="Tom Clancy" name="author">
<meta content="
The OAuth 2.0 protocol framework defines a mechanism to allow a
resource owner to delegate access to a protected resource for a
client
application.
This specification profiles the OAuth 2.0 protocol framework to
increase baseline security, provide greater interoperability, and
structure deployments in a manner specifically applicable, but not limited to
consumer-to-government deployments.
" name="description">
<meta content="xml2rfc 3.28.1" name="generator">
<meta content="openid-igov-oauth2-1_06" name="ietf.draft">
<!-- Generator version information:
xml2rfc 3.28.1
Python 3.12.3
ConfigArgParse 1.7
google-i18n-address 3.1.1
intervaltree 3.1.0
Jinja2 3.1.6
lxml 5.3.1
platformdirs 4.3.7
pycountry 24.6.1
PyYAML 6.0.2
requests 2.32.3
setuptools 78.1.0
wcwidth 0.2.13
weasyprint 65.0
-->
<link href="openid-igov-oauth2-1_0.xml" rel="alternate" type="application/rfc+xml">
<link href="#copyright" rel="license">
<style type="text/css">/*
NOTE: Changes at the bottom of this file overrides some earlier settings.
Once the style has stabilized and has been adopted as an official RFC style,
this can be consolidated so that style settings occur only in one place, but
for now the contents of this file consists first of the initial CSS work as
provided to the RFC Formatter (xml2rfc) work, followed by itemized and
commented changes found necessary during the development of the v3
formatters.
*/
/* fonts */
@import url('https://fonts.googleapis.com/css?family=Noto+Sans'); /* Sans-serif */
@import url('https://fonts.googleapis.com/css?family=Noto+Serif'); /* Serif (print) */
@import url('https://fonts.googleapis.com/css?family=Roboto+Mono'); /* Monospace */
:root {
--font-sans: 'Noto Sans', Arial, Helvetica, sans-serif;
--font-serif: 'Noto Serif', 'Times', 'Times New Roman', serif;
--font-mono: 'Roboto Mono', Courier, 'Courier New', monospace;
}
@viewport {
zoom: 1.0;
}
@-ms-viewport {
width: extend-to-zoom;
zoom: 1.0;
}
/* general and mobile first */
html {
}
body {
max-width: 90%;
margin: 1.5em auto;
color: #222;
background-color: #fff;
font-size: 14px;
font-family: var(--font-sans);
line-height: 1.6;
scroll-behavior: smooth;
overflow-wrap: break-word;
}
.ears {
display: none;
}
/* headings */
#title, h1, h2, h3, h4, h5, h6 {
margin: 1em 0 0.5em;
font-weight: bold;
line-height: 1.3;
}
#title {
clear: both;
border-bottom: 1px solid #ddd;
margin: 0 0 0.5em 0;
padding: 1em 0 0.5em;
}
.author {
padding-bottom: 4px;
}
h1 {
font-size: 26px;
margin: 1em 0;
}
h2 {
font-size: 22px;
margin-top: -20px; /* provide offset for in-page anchors */
padding-top: 33px;
}
h3 {
font-size: 18px;
margin-top: -36px; /* provide offset for in-page anchors */
padding-top: 42px;
}
h4 {
font-size: 16px;
margin-top: -36px; /* provide offset for in-page anchors */
padding-top: 42px;
}
h5, h6 {
font-size: 14px;
}
#n-copyright-notice {
border-bottom: 1px solid #ddd;
padding-bottom: 1em;
margin-bottom: 1em;
}
/* general structure */
p {
padding: 0;
margin: 0 0 1em 0;
text-align: left;
}
div, span {
position: relative;
}
div {
margin: 0;
}
.alignRight.art-text {
background-color: #f9f9f9;
border: 1px solid #eee;
border-radius: 3px;
padding: 1em 1em 0;
margin-bottom: 1.5em;
}
.alignRight.art-text pre {
padding: 0;
}
.alignRight {
margin: 1em 0;
}
.alignRight > *:first-child {
border: none;
margin: 0;
float: right;
clear: both;
}
.alignRight > *:nth-child(2) {
clear: both;
display: block;
border: none;
}
svg {
display: block;
}
svg[font-family~="serif" i], svg [font-family~="serif" i] {
font-family: var(--font-serif);
}
svg[font-family~="sans-serif" i], svg [font-family~="sans-serif" i] {
font-family: var(--font-sans);
}
svg[font-family~="monospace" i], svg [font-family~="monospace" i] {
font-family: var(--font-mono);
}
.alignCenter.art-text {
background-color: #f9f9f9;
border: 1px solid #eee;
border-radius: 3px;
padding: 1em 1em 0;
margin-bottom: 1.5em;
}
.alignCenter.art-text pre {
padding: 0;
}
.alignCenter {
margin: 1em 0;
}
.alignCenter > *:first-child {
display: table;
border: none;
margin: 0 auto;
}
/* lists */
ol, ul {
padding: 0;
margin: 0 0 1em 2em;
}
ol ol, ul ul, ol ul, ul ol {
margin-left: 1em;
}
li {
margin: 0 0 0.25em 0;
}
.ulCompact li {
margin: 0;
}
ul.empty, .ulEmpty {
list-style-type: none;
}
ul.empty li, .ulEmpty li {
margin-top: 0.5em;
}
ul.ulBare, li.ulBare {
margin-left: 0em !important;
}
ul.compact, .ulCompact,
ol.compact, .olCompact {
line-height: 100%;
margin: 0 0 0 2em;
}
/* definition lists */
dl {
}
dl > dt {
float: left;
margin-right: 1em;
}
/*
dl.nohang > dt {
float: none;
}
*/
dl > dd {
margin-bottom: .8em;
min-height: 1.3em;
}
dl.compact > dd, .dlCompact > dd {
margin-bottom: 0em;
}
dl > dd > dl {
margin-top: 0.5em;
margin-bottom: 0em;
}
/* links */
a {
text-decoration: none;
}
a[href] {
color: #22e; /* Arlen: WCAG 2019 */
}
a[href]:hover {
background-color: #f2f2f2;
}
figcaption a[href],
a[href].selfRef {
color: #222;
}
/* XXX probably not this:
a.selfRef:hover {
background-color: transparent;
cursor: default;
} */
/* Figures */
tt, code, pre {
background-color: #f9f9f9;
font-family: var(--font-mono);
}
pre {
border: 1px solid #eee;
margin: 0;
padding: 1em;
}
img {
max-width: 100%;
}
figure {
margin: 0;
}
figure blockquote {
margin: 0.8em 0.4em 0.4em;
}
figcaption {
font-style: italic;
margin: 0 0 1em 0;
}
@media screen {
pre {
overflow-x: auto;
max-width: 100%;
max-width: calc(100% - 22px);
}
}
/* aside, blockquote */
aside, blockquote {
margin-left: 0;
padding: 1.2em 2em;
}
blockquote {
background-color: #f9f9f9;
color: #111; /* Arlen: WCAG 2019 */
border: 1px solid #ddd;
border-radius: 3px;
margin: 1em 0;
}
blockquote > *:last-child {
margin-bottom: 0;
}
cite {
display: block;
text-align: right;
font-style: italic;
}
.xref {
overflow-wrap: normal;
}
/* tables */
table {
width: 100%;
margin: 0 0 1em;
border-collapse: collapse;
border: 1px solid #eee;
}
th, td {
text-align: left;
vertical-align: top;
padding: 0.5em 0.75em;
}
th {
text-align: left;
background-color: #e9e9e9;
}
tr:nth-child(2n+1) > td {
background-color: #f5f5f5;
}
table caption {
font-style: italic;
margin: 0;
padding: 0;
text-align: left;
}
table p {
/* XXX to avoid bottom margin on table row signifiers. If paragraphs should
be allowed within tables more generally, it would be far better to select on a class. */
margin: 0;
}
/* pilcrow */
a.pilcrow {
color: #666; /* Arlen: AHDJ 2019 */
text-decoration: none;
visibility: hidden;
user-select: none;
-ms-user-select: none;
-o-user-select:none;
-moz-user-select: none;
-khtml-user-select: none;
-webkit-user-select: none;
-webkit-touch-callout: none;
}
@media screen {
aside:hover > a.pilcrow,
p:hover > a.pilcrow,
blockquote:hover > a.pilcrow,
div:hover > a.pilcrow,
li:hover > a.pilcrow,
pre:hover > a.pilcrow {
visibility: visible;
}
a.pilcrow:hover {
background-color: transparent;
}
}
/* misc */
hr {
border: 0;
border-top: 1px solid #eee;
}
.bcp14 {
font-variant: small-caps;
}
.role {
font-variant: all-small-caps;
}
/* info block */
#identifiers {
margin: 0;
font-size: 0.9em;
}
#identifiers dt {
width: 3em;
clear: left;
}
#identifiers dd {
float: left;
margin-bottom: 0;
}
/* Fix PDF info block run off issue */
@media print {
#identifiers dd {
max-width: 100%;
}
}
#identifiers .authors .author {
display: inline-block;
margin-right: 1.5em;
}
#identifiers .authors .org {
font-style: italic;
}
/* The prepared/rendered info at the very bottom of the page */
.docInfo {
color: #666; /* Arlen: WCAG 2019 */
font-size: 0.9em;
font-style: italic;
margin-top: 2em;
}
.docInfo .prepared {
float: left;
}
.docInfo .prepared {
float: right;
}
/* table of contents */
#toc {
padding: 0.75em 0 2em 0;
margin-bottom: 1em;
}
nav.toc ul {
margin: 0 0.5em 0 0;
padding: 0;
list-style: none;
}
nav.toc li {
line-height: 1.3em;
margin: 0.75em 0;
padding-left: 1.2em;
text-indent: -1.2em;
}
/* references */
.references dt {
text-align: right;
font-weight: bold;
min-width: 7em;
}
.references dd {
margin-left: 8em;
overflow: auto;
}
.refInstance {
margin-bottom: 1.25em;
}
.refSubseries {
margin-bottom: 1.25em;
}
.references .ascii {
margin-bottom: 0.25em;
}
/* index */
.index ul {
margin: 0 0 0 1em;
padding: 0;
list-style: none;
}
.index ul ul {
margin: 0;
}
.index li {
margin: 0;
text-indent: -2em;
padding-left: 2em;
padding-bottom: 5px;
}
.indexIndex {
margin: 0.5em 0 1em;
}
.index a {
font-weight: 700;
}
/* make the index two-column on all but the smallest screens */
@media (min-width: 600px) {
.index ul {
-moz-column-count: 2;
-moz-column-gap: 20px;
}
.index ul ul {
-moz-column-count: 1;
-moz-column-gap: 0;
}
}
/* authors */
address.vcard {
font-style: normal;
margin: 1em 0;
}
address.vcard .nameRole {
font-weight: 700;
margin-left: 0;
}
address.vcard .label {
font-family: var(--font-sans);
margin: 0.5em 0;
}
address.vcard .type {
display: none;
}
.alternative-contact {
margin: 1.5em 0 1em;
}
hr.addr {
border-top: 1px dashed;
margin: 0;
color: #ddd;
max-width: calc(100% - 16px);
}
/* temporary notes */
.rfcEditorRemove::before {
position: absolute;
top: 0.2em;
right: 0.2em;
padding: 0.2em;
content: "The RFC Editor will remove this note";
color: #9e2a00; /* Arlen: WCAG 2019 */
background-color: #ffd; /* Arlen: WCAG 2019 */
}
.rfcEditorRemove {
position: relative;
padding-top: 1.8em;
background-color: #ffd; /* Arlen: WCAG 2019 */
border-radius: 3px;
}
.cref {
background-color: #ffd; /* Arlen: WCAG 2019 */
padding: 2px 4px;
}
.crefSource {
font-style: italic;
}
/* alternative layout for smaller screens */
@media screen and (max-width: 1023px) {
body {
padding-top: 2em;
}
#title {
padding: 1em 0;
}
h1 {
font-size: 24px;
}
h2 {
font-size: 20px;
margin-top: -18px; /* provide offset for in-page anchors */
padding-top: 38px;
}
#identifiers dd {
max-width: 60%;
}
#toc {
position: fixed;
z-index: 2;
top: 0;
right: 0;
padding: 0;
margin: 0;
background-color: inherit;
border-bottom: 1px solid #ccc;
}
#toc h2 {
margin: -1px 0 0 0;
padding: 4px 0 4px 6px;
padding-right: 1em;
min-width: 190px;
font-size: 1.1em;
text-align: right;
background-color: #444;
color: white;
cursor: pointer;
}
#toc h2::before { /* css hamburger */
float: right;
position: relative;
width: 1em;
height: 1px;
left: -164px;
margin: 6px 0 0 0;
background: white none repeat scroll 0 0;
box-shadow: 0 4px 0 0 white, 0 8px 0 0 white;
content: "";
}
#toc nav {
display: none;
padding: 0.5em 1em 1em;
overflow: auto;
height: calc(100vh - 48px);
border-left: 1px solid #ddd;
}
}
/* alternative layout for wide screens */
@media screen and (min-width: 1024px) {
body {
max-width: 724px;
margin: 42px auto;
padding-left: 1.5em;
padding-right: 29em;
}
#toc {
position: fixed;
top: 42px;
right: 42px;
width: 25%;
margin: 0;
padding: 0 1em;
z-index: 1;
}
#toc h2 {
border-top: none;
border-bottom: 1px solid #ddd;
font-size: 1em;
font-weight: normal;
margin: 0;
padding: 0.25em 1em 1em 0;
}
#toc nav {
display: block;
height: calc(90vh - 84px);
bottom: 0;
padding: 0.5em 0 0;
overflow: auto;
}
img { /* future proofing */
max-width: 100%;
height: auto;
}
}
/* pagination */
@media print {
body {
width: 100%;
}
p {
orphans: 3;
widows: 3;
}
#n-copyright-notice {
border-bottom: none;
}
#toc, #n-introduction {
page-break-before: always;
}
#toc {
border-top: none;
padding-top: 0;
}
figure, pre {
page-break-inside: avoid;
}
figure {
overflow: scroll;
}
.breakable pre {
break-inside: auto;
}
h1, h2, h3, h4, h5, h6 {
page-break-after: avoid;
}
h2+*, h3+*, h4+*, h5+*, h6+* {
page-break-before: avoid;
}
pre {
white-space: pre-wrap;
word-wrap: break-word;
font-size: 10pt;
}
table {
border: 1px solid #ddd;
}
td {
border-top: 1px solid #ddd;
}
}
/* This is commented out here, as the string-set: doesn't
pass W3C validation currently */
/*
.ears thead .left {
string-set: ears-top-left content();
}
.ears thead .center {
string-set: ears-top-center content();
}
.ears thead .right {
string-set: ears-top-right content();
}
.ears tfoot .left {
string-set: ears-bottom-left content();
}
.ears tfoot .center {
string-set: ears-bottom-center content();
}
.ears tfoot .right {
string-set: ears-bottom-right content();
}
*/
@page :first {
padding-top: 0;
@top-left {
content: normal;
border: none;
}
@top-center {
content: normal;
border: none;
}
@top-right {
content: normal;
border: none;
}
}
@page {
size: A4;
margin-bottom: 45mm;
padding-top: 20px;
/* The following is commented out here, but set appropriately by in code, as
the content depends on the document */
/*
@top-left {
content: 'Internet-Draft';
vertical-align: bottom;
border-bottom: solid 1px #ccc;
}
@top-left {
content: string(ears-top-left);
vertical-align: bottom;
border-bottom: solid 1px #ccc;
}
@top-center {
content: string(ears-top-center);
vertical-align: bottom;
border-bottom: solid 1px #ccc;
}
@top-right {
content: string(ears-top-right);
vertical-align: bottom;
border-bottom: solid 1px #ccc;
}
@bottom-left {
content: string(ears-bottom-left);
vertical-align: top;
border-top: solid 1px #ccc;
}
@bottom-center {
content: string(ears-bottom-center);
vertical-align: top;
border-top: solid 1px #ccc;
}
@bottom-right {
content: '[Page ' counter(page) ']';
vertical-align: top;
border-top: solid 1px #ccc;
}
*/
}
/* Changes introduced to fix issues found during implementation */
/* Make sure links are clickable even if overlapped by following H* */
a {
z-index: 2;
}
/* Separate body from document info even without intervening H1 */
section {
clear: both;
}
/* Top align author divs, to avoid names without organization dropping level with org names */
.author {
vertical-align: top;
}
/* Leave room in document info to show Internet-Draft on one line */
#identifiers dt {
width: 8em;
}
/* Don't waste quite as much whitespace between label and value in doc info */
#identifiers dd {
margin-left: 1em;
}
/* Give floating toc a background color (needed when it's a div inside section */
#toc {
background-color: white;
}
/* Make the collapsed ToC header render white on gray also when it's a link */
@media screen and (max-width: 1023px) {
#toc h2 a,
#toc h2 a:link,
#toc h2 a:focus,
#toc h2 a:hover,
#toc a.toplink,
#toc a.toplink:hover {
color: white;
background-color: #444;
text-decoration: none;
}
}
/* Give the bottom of the ToC some whitespace */
@media screen and (min-width: 1024px) {
#toc {
padding: 0 0 1em 1em;
}
}
/* Style section numbers with more space between number and title */
.section-number {
padding-right: 0.5em;
}
/* prevent monospace from becoming overly large */
tt, code, pre {
font-size: 95%;
}
/* Fix the height/width aspect for ascii art*/
.sourcecode pre,
.art-text pre {
line-height: 1.12;
}
/* Add styling for a link in the ToC that points to the top of the document */
a.toplink {
float: right;
margin-right: 0.5em;
}
/* Fix the dl styling to match the RFC 7992 attributes */
dl > dt,
dl.dlParallel > dt {
float: left;
margin-right: 1em;
}
dl.dlNewline > dt {
float: none;
}
/* Provide styling for table cell text alignment */
table td.text-left,
table th.text-left {
text-align: left;
}
table td.text-center,
table th.text-center {
text-align: center;
}
table td.text-right,
table th.text-right {
text-align: right;
}
/* Make the alternative author contact information look less like just another
author, and group it closer with the primary author contact information */
.alternative-contact {
margin: 0.5em 0 0.25em 0;
}
address .non-ascii {
margin: 0 0 0 2em;
}
/* With it being possible to set tables with alignment
left, center, and right, { width: 100%; } does not make sense */
table {
width: auto;
}
/* Avoid reference text that sits in a block with very wide left margin,
because of a long floating dt label.*/
.references dd {
overflow: visible;
}
/* Control caption placement */
caption {
caption-side: bottom;
}
/* Limit the width of the author address vcard, so names in right-to-left
script don't end up on the other side of the page. */
address.vcard {
max-width: 30em;
margin-right: auto;
}
/* For address alignment dependent on LTR or RTL scripts */
address div.left {
text-align: left;
}
address div.right {
text-align: right;
}
/* Provide table alignment support. We can't use the alignX classes above
since they do unwanted things with caption and other styling. */
table.right {
margin-left: auto;
margin-right: 0;
}
table.center {
margin-left: auto;
margin-right: auto;
}
table.left {
margin-left: 0;
margin-right: auto;
}
/* Give the table caption label the same styling as the figcaption */
caption a[href] {
color: #222;
}
@media print {
.toplink {
display: none;
}
/* avoid overwriting the top border line with the ToC header */
#toc {
padding-top: 1px;
}
/* Avoid page breaks inside dl and author address entries */
.vcard {
page-break-inside: avoid;
}
}
/* Tweak the bcp14 keyword presentation */
.bcp14 {
font-variant: small-caps;
font-weight: bold;
font-size: 0.9em;
}
/* Tweak the invisible space above H* in order not to overlay links in text above */
h2 {
margin-top: -18px; /* provide offset for in-page anchors */
padding-top: 31px;
}
h3 {
margin-top: -18px; /* provide offset for in-page anchors */
padding-top: 24px;
}
h4 {
margin-top: -18px; /* provide offset for in-page anchors */
padding-top: 24px;
}
/* Float artwork pilcrow to the right */
@media screen {
.artwork a.pilcrow {
display: block;
line-height: 0.7;
margin-top: 0.15em;
}
}
/* Make pilcrows on dd visible */
@media screen {
dd:hover > a.pilcrow {
visibility: visible;
}
}
/* Make the placement of figcaption match that of a table's caption
by removing the figure's added bottom margin */
.alignLeft.art-text,
.alignCenter.art-text,
.alignRight.art-text {
margin-bottom: 0;
}
.alignLeft,
.alignCenter,
.alignRight {
margin: 1em 0 0 0;
}
/* In print, the pilcrow won't show on hover, so prevent it from taking up space,
possibly even requiring a new line */
@media print {
a.pilcrow {
display: none;
}
}
/* Styling for the external metadata */
div#external-metadata {
background-color: #eee;
padding: 0.5em;
margin-bottom: 0.5em;
display: none;
}
div#internal-metadata {
padding: 0.5em; /* to match the external-metadata padding */
}
/* Styling for title RFC Number */
h1#rfcnum {
clear: both;
margin: 0 0 -1em;
padding: 1em 0 0 0;
}
/* Make .olPercent look the same as <ol><li> */
dl.olPercent > dd {
margin-bottom: 0.25em;
min-height: initial;
}
/* Give aside some styling to set it apart */
aside {
border-left: 1px solid #ddd;
margin: 1em 0 1em 2em;
padding: 0.2em 2em;
}
aside > dl,
aside > ol,
aside > ul,
aside > table,
aside > p {
margin-bottom: 0.5em;
}
/* Additional page break settings */
@media print {
figcaption, table caption {
page-break-before: avoid;
}
}
/* Font size adjustments for print */
@media print {
body { font-size: 10pt; line-height: normal; max-width: 96%; }
h1 { font-size: 1.72em; padding-top: 1.5em; } /* 1*1.2*1.2*1.2 */
h2 { font-size: 1.44em; padding-top: 1.5em; } /* 1*1.2*1.2 */
h3 { font-size: 1.2em; padding-top: 1.5em; } /* 1*1.2 */
h4 { font-size: 1em; padding-top: 1.5em; }
h5, h6 { font-size: 1em; margin: initial; padding: 0.5em 0 0.3em; }
}
/* Sourcecode margin in print, when there's no pilcrow */
@media print {
.artwork,
.artwork > pre,
.sourcecode {
margin-bottom: 1em;
}
}
/* Avoid narrow tables forcing too narrow table captions, which may render badly */
table {
min-width: 20em;
}
/* ol type a */
ol.type-a { list-style-type: lower-alpha; }
ol.type-A { list-style-type: upper-alpha; }
ol.type-i { list-style-type: lower-roman; }
ol.type-I { list-style-type: upper-roman; }
/* Apply the print table and row borders in general, on request from the RPC,
and increase the contrast between border and odd row background slightly */
table {
border: 1px solid #ddd;
}
td {
border-top: 1px solid #ddd;
}
tr {
break-inside: avoid;
}
tr:nth-child(2n+1) > td {
background-color: #f8f8f8;
}
/* Use style rules to govern display of the TOC. */
@media screen and (max-width: 1023px) {
#toc nav { display: none; }
#toc.active nav { display: block; }
}
/* Add support for keepWithNext */
.keepWithNext {
break-after: avoid-page;
break-after: avoid-page;
}
/* Add support for keepWithPrevious */
.keepWithPrevious {
break-before: avoid-page;
}
/* Change the approach to avoiding breaks inside artwork etc. */
figure, pre, table, .artwork, .sourcecode {
break-before: auto;
break-after: auto;
}
/* Avoid breaks between <dt> and <dd> */
dl {
break-before: auto;
break-inside: auto;
}
dt {
break-before: auto;
break-after: avoid-page;
}
dd {
break-before: avoid-page;
break-after: auto;
orphans: 3;
widows: 3
}
span.break, dd.break {
margin-bottom: 0;
min-height: 0;
break-before: auto;
break-inside: auto;
break-after: auto;
}
/* Undo break-before ToC */
@media print {
#toc {
break-before: auto;
}
}
/* Text in compact lists should not get extra bottom margin space,
since that would makes the list not compact */
ul.compact p, .ulCompact p,
ol.compact p, .olCompact p {
margin: 0;
}
/* But the list as a whole needs the extra space at the end */
section ul.compact,
section .ulCompact,
section ol.compact,
section .olCompact {
margin-bottom: 1em; /* same as p not within ul.compact etc. */
}
/* The tt and code background above interferes with for instance table cell
backgrounds. Changed to something a bit more selective. */
tt, code {
background-color: transparent;
}
p tt, p code, li tt, li code, dt tt, dt code {
background-color: #f8f8f8;
}
/* Tweak the pre margin -- 0px doesn't come out well */
pre {
margin-top: 0.5px;
}
/* Tweak the compact list text */
ul.compact, .ulCompact,
ol.compact, .olCompact,
dl.compact, .dlCompact {
line-height: normal;
}
/* Don't add top margin for nested lists */
li > ul, li > ol, li > dl,
dd > ul, dd > ol, dd > dl,
dl > dd > dl {
margin-top: initial;
}
/* Elements that should not be rendered on the same line as a <dt> */
/* This should match the element list in writer.text.TextWriter.render_dl() */
dd > div.artwork:first-child,
dd > aside:first-child,
dd > figure:first-child,
dd > ol:first-child,
dd > div.sourcecode:first-child,
dd > table:first-child,
dd > ul:first-child {
clear: left;
}
/* fix for weird browser behaviour when <dd/> is empty */
dt+dd:empty::before{
content: "\00a0";
}
/* Make paragraph spacing inside <li> smaller than in body text, to fit better within the list */
li > p {
margin-bottom: 0.5em
}
/* Don't let p margin spill out from inside list items */
li > p:last-of-type:only-child {
margin-bottom: 0;
}
</style>
<link href="rfc-local.css" rel="stylesheet" type="text/css">
<script type="application/javascript">async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(let t=0;t<e.length;t++)if(/#identifiers/.exec(e[t].selectorText)){const a=e[t].cssText.replace("#identifiers","#external-updates");document.styleSheets[0].insertRule(a,document.styleSheets[0].cssRules.length)}}catch(e){console.log(e)}const e=document.getElementById("external-metadata");if(e)try{var t,a="",o=function(e){const t=document.getElementsByTagName("meta");for(let a=0;a<t.length;a++)if(t[a].getAttribute("name")===e)return t[a].getAttribute("content");return""}("rfc.number");if(o){t="https://www.rfc-editor.org/rfc/rfc"+o+".json";try{const e=await fetch(t);a=await e.json()}catch(e){t=document.URL.indexOf("html")>=0?document.URL.replace(/html$/,"json"):document.URL+".json";const o=await fetch(t);a=await o.json()}}if(!a)return;e.style.display="block";const s="",d="https://datatracker.ietf.org/doc",n="https://datatracker.ietf.org/ipr/search",c="https://www.rfc-editor.org/info",l=a.doc_id.toLowerCase(),i=a.doc_id.slice(0,3).toLowerCase(),f=a.doc_id.slice(3).replace(/^0+/,""),u={status:"Status",obsoletes:"Obsoletes",obsoleted_by:"Obsoleted By",updates:"Updates",updated_by:"Updated By",see_also:"See Also",errata_url:"Errata"};let h="<dl style='overflow:hidden' id='external-updates'>";["status","obsoletes","obsoleted_by","updates","updated_by","see_also","errata_url"].forEach(e=>{if("status"==e){a[e]=a[e].toLowerCase();var t=a[e].split(" "),o=t.length,w="",p=1;for(let e=0;e<o;e++)p<o?w=w+r(t[e])+" ":w+=r(t[e]),p++;a[e]=w}else if("obsoletes"==e||"obsoleted_by"==e||"updates"==e||"updated_by"==e){var g,m="",b=1;g=a[e].length;for(let t=0;t<g;t++)a[e][t]&&(a[e][t]=String(a[e][t]).toLowerCase(),m=b<g?m+"<a href='"+s+"/rfc/".concat(a[e][t])+"'>"+a[e][t].slice(3)+"</a>, ":m+"<a href='"+s+"/rfc/".concat(a[e][t])+"'>"+a[e][t].slice(3)+"</a>",b++);a[e]=m}else if("see_also"==e){var y,L="",C=1;y=a[e].length;for(let t=0;t<y;t++)if(a[e][t]){a[e][t]=String(a[e][t]);var _=a[e][t].slice(0,3),v=a[e][t].slice(3).replace(/^0+/,"");L=C<y?"RFC"!=_?L+"<a href='"+s+"/info/"+_.toLowerCase().concat(v.toLowerCase())+"'>"+_+" "+v+"</a>, ":L+"<a href='"+s+"/info/"+_.toLowerCase().concat(v.toLowerCase())+"'>"+v+"</a>, ":"RFC"!=_?L+"<a href='"+s+"/info/"+_.toLowerCase().concat(v.toLowerCase())+"'>"+_+" "+v+"</a>":L+"<a href='"+s+"/info/"+_.toLowerCase().concat(v.toLowerCase())+"'>"+v+"</a>",C++}a[e]=L}else if("errata_url"==e){var R="";R=a[e]?R+"<a href='"+a[e]+"'>Errata exist</a> | <a href='"+d+"/"+l+"'>Datatracker</a>| <a href='"+n+"/?"+i+"="+f+"&submit="+i+"'>IPR</a> | <a href='"+c+"/"+l+"'>Info page</a>":"<a href='"+d+"/"+l+"'>Datatracker</a> | <a href='"+n+"/?"+i+"="+f+"&submit="+i+"'>IPR</a> | <a href='"+c+"/"+l+"'>Info page</a>",a[e]=R}""!=a[e]?"Errata"==u[e]?h+=`<dt>More info:</dt><dd>${a[e]}</dd>`:h+=`<dt>${u[e]}:</dt><dd>${a[e]}</dd>`:"Errata"==u[e]&&(h+=`<dt>More info:</dt><dd>${a[e]}</dd>`)}),h+="</dl>",e.innerHTML=h}catch(e){console.log(e)}else console.log("Could not locate metadata <div> element");function r(e){return e.charAt(0).toUpperCase()+e.slice(1)}}window.removeEventListener("load",addMetadata),window.addEventListener("load",addMetadata);</script>
</head>
<body class="xml2rfc">
<script src="metadata.min.js"></script>
<table class="ears">
<thead><tr>
<td class="left"></td>
<td class="center">iGov OAuth 2.0</td>
<td class="right">April 2025</td>
</tr></thead>
<tfoot><tr>
<td class="left">Burgin & Clancy</td>
<td class="center">Standards Track</td>
<td class="right">[Page]</td>
</tr></tfoot>
</table>
<div id="external-metadata" class="document-information"></div>
<div id="internal-metadata" class="document-information">
<dl id="identifiers">
<dt class="label-workgroup">Workgroup:</dt>
<dd class="workgroup">OpenID iGov Working Group</dd>
<dt class="label-published">Published:</dt>
<dd class="published">
<time datetime="2025-04-26" class="published">26 April 2025</time>
</dd>
<dt class="label-authors">Authors:</dt>
<dd class="authors">
<div class="author">
<div class="author-name">K. Burgin, <span class="editor">Ed.</span>
</div>
<div class="org">MITRE</div>
</div>
<div class="author">
<div class="author-name">T. Clancy, <span class="editor">Ed.</span>
</div>
<div class="org">MITRE</div>
</div>
</dd>
</dl>
</div>
<h1 id="title">International Government Assurance Profile (iGov) for OAuth 2.0 - draft 07</h1>
<section id="section-abstract">
<h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
<p id="section-abstract-1">The OAuth 2.0 protocol framework defines a mechanism to allow a
resource owner to delegate access to a protected resource for a
client
application.<a href="#section-abstract-1" class="pilcrow">¶</a></p>
<p id="section-abstract-2">This specification profiles the OAuth 2.0 protocol framework to
increase baseline security, provide greater interoperability, and
structure deployments in a manner specifically applicable, but not limited to
consumer-to-government deployments.<a href="#section-abstract-2" class="pilcrow">¶</a></p>
</section>
<div id="toc">
<section id="section-toc.1">
<a href="#" onclick="scroll(0,0)" class="toplink">▲</a><h2 id="name-table-of-contents">
<a href="#name-table-of-contents" class="section-name selfRef">Table of Contents</a>
</h2>
<nav class="toc"><ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.1">
<p id="section-toc.1-1.1.1"><a href="#section-1" class="auto internal xref">1</a>. <a href="#name-introduction" class="internal xref">Introduction</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.1.2.1">
<p id="section-toc.1-1.1.2.1.1" class="keepWithNext"><a href="#section-1.1" class="auto internal xref">1.1</a>. <a href="#name-requirements-notation-and-c" class="internal xref">Requirements Notation and Conventions</a></p>
</li>
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.1.2.2">
<p id="section-toc.1-1.1.2.2.1" class="keepWithNext"><a href="#section-1.2" class="auto internal xref">1.2</a>. <a href="#name-terminology" class="internal xref">Terminology</a></p>
</li>
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.1.2.3">
<p id="section-toc.1-1.1.2.3.1" class="keepWithNext"><a href="#section-1.3" class="auto internal xref">1.3</a>. <a href="#name-conformance" class="internal xref">Conformance</a></p>
</li>
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.1.2.4">
<p id="section-toc.1-1.1.2.4.1"><a href="#section-1.4" class="auto internal xref">1.4</a>. <a href="#name-global-requirements" class="internal xref">Global Requirements</a></p>
</li>
</ul>
</li>
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2">
<p id="section-toc.1-1.2.1"><a href="#section-2" class="auto internal xref">2</a>. <a href="#name-client-profiles" class="internal xref">Client Profiles</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2.2.1">
<p id="section-toc.1-1.2.2.1.1"><a href="#section-2.1" class="auto internal xref">2.1</a>. <a href="#name-client-types" class="internal xref">Client Types</a></p>
</li>
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2.2.2">
<p id="section-toc.1-1.2.2.2.1"><a href="#section-2.2" class="auto internal xref">2.2</a>. <a href="#name-client-type-use-cases" class="internal xref">Client Type Use Cases</a></p>
</li>
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2.2.3">
<p id="section-toc.1-1.2.2.3.1"><a href="#section-2.3" class="auto internal xref">2.3</a>. <a href="#name-client-registration" class="internal xref">Client Registration</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2.2.3.2.1">
<p id="section-toc.1-1.2.2.3.2.1.1"><a href="#section-2.3.1" class="auto internal xref">2.3.1</a>. <a href="#name-redirect-uri" class="internal xref">Redirect URI</a></p>
</li>
</ul>
</li>
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2.2.4">
<p id="section-toc.1-1.2.2.4.1"><a href="#section-2.4" class="auto internal xref">2.4</a>. <a href="#name-sender-constrained-tokens" class="internal xref">Sender-constrained Tokens</a></p>
</li>
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2.2.5">
<p id="section-toc.1-1.2.2.5.1"><a href="#section-2.5" class="auto internal xref">2.5</a>. <a href="#name-authentication-context-and-" class="internal xref">Authentication Context and Step-Up Authentication Challenge Protocol Support</a></p>
</li>
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2.2.6">
<p id="section-toc.1-1.2.2.6.1"><a href="#section-2.6" class="auto internal xref">2.6</a>. <a href="#name-connection-to-the-authoriza" class="internal xref">Connection to the Authorization Server</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2.2.6.2.1">
<p id="section-toc.1-1.2.2.6.2.1.1"><a href="#section-2.6.1" class="auto internal xref">2.6.1</a>. <a href="#name-requests-to-the-authorizati" class="internal xref">Requests to the Authorization Endpoint</a></p>
</li>
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2.2.6.2.2">
<p id="section-toc.1-1.2.2.6.2.2.1"><a href="#section-2.6.2" class="auto internal xref">2.6.2</a>. <a href="#name-requests-to-the-token-endpo" class="internal xref">Requests to the Token Endpoint</a></p>
</li>
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2.2.6.2.3">
<p id="section-toc.1-1.2.2.6.2.3.1"><a href="#section-2.6.3" class="auto internal xref">2.6.3</a>. <a href="#name-client-keys" class="internal xref">Client Keys</a></p>
</li>
</ul>
</li>
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2.2.7">
<p id="section-toc.1-1.2.2.7.1"><a href="#section-2.7" class="auto internal xref">2.7</a>. <a href="#name-connection-to-the-protected" class="internal xref">Connection to the Protected Resource</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2.2.7.2.1">
<p id="section-toc.1-1.2.2.7.2.1.1"><a href="#section-2.7.1" class="auto internal xref">2.7.1</a>. <a href="#name-requests-to-the-protected-r" class="internal xref">Requests to the Protected Resource</a></p>
</li>
</ul>
</li>
</ul>
</li>
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3">
<p id="section-toc.1-1.3.1"><a href="#section-3" class="auto internal xref">3</a>. <a href="#name-authorization-server-profil" class="internal xref">Authorization Server Profile</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.1">
<p id="section-toc.1-1.3.2.1.1"><a href="#section-3.1" class="auto internal xref">3.1</a>. <a href="#name-connections-with-clients" class="internal xref">Connections with clients</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.1.2.1">
<p id="section-toc.1-1.3.2.1.2.1.1"><a href="#section-3.1.1" class="auto internal xref">3.1.1</a>. <a href="#name-grant-types" class="internal xref">Grant types</a></p>
</li>
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.1.2.2">
<p id="section-toc.1-1.3.2.1.2.2.1"><a href="#section-3.1.2" class="auto internal xref">3.1.2</a>. <a href="#name-client-authentication" class="internal xref">Client authentication</a></p>
</li>
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.1.2.3">
<p id="section-toc.1-1.3.2.1.2.3.1"><a href="#section-3.1.3" class="auto internal xref">3.1.3</a>. <a href="#name-dynamic-registration" class="internal xref">Dynamic Registration</a></p>
</li>
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.1.2.4">
<p id="section-toc.1-1.3.2.1.2.4.1"><a href="#section-3.1.4" class="auto internal xref">3.1.4</a>. <a href="#name-client-approval" class="internal xref">Client Approval</a></p>
</li>
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.1.2.5">
<p id="section-toc.1-1.3.2.1.2.5.1"><a href="#section-3.1.5" class="auto internal xref">3.1.5</a>. <a href="#name-sender-constrained-tokens-2" class="internal xref">Sender-constrained Tokens</a></p>
</li>
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.1.2.6">
<p id="section-toc.1-1.3.2.1.2.6.1"><a href="#section-3.1.6" class="auto internal xref">3.1.6</a>. <a href="#name-discovery" class="internal xref">Discovery</a></p>
</li>
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.1.2.7">
<p id="section-toc.1-1.3.2.1.2.7.1"><a href="#section-3.1.7" class="auto internal xref">3.1.7</a>. <a href="#name-revocation" class="internal xref">Revocation</a></p>
</li>
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.1.2.8">
<p id="section-toc.1-1.3.2.1.2.8.1"><a href="#section-3.1.8" class="auto internal xref">3.1.8</a>. <a href="#name-pkce" class="internal xref">PKCE</a></p>
</li>
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.1.2.9">
<p id="section-toc.1-1.3.2.1.2.9.1"><a href="#section-3.1.9" class="auto internal xref">3.1.9</a>. <a href="#name-redirect-uris" class="internal xref">Redirect URIs</a></p>
</li>
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.1.2.10">
<p id="section-toc.1-1.3.2.1.2.10.1"><a href="#section-3.1.10" class="auto internal xref">3.1.10</a>. <a href="#name-refresh-tokens" class="internal xref">Refresh Tokens</a></p>
</li>
</ul>
</li>
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.2">
<p id="section-toc.1-1.3.2.2.1"><a href="#section-3.2" class="auto internal xref">3.2</a>. <a href="#name-response-to-authorization-r" class="internal xref">Response to Authorization Requests</a></p>
</li>
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.3">
<p id="section-toc.1-1.3.2.3.1"><a href="#section-3.3" class="auto internal xref">3.3</a>. <a href="#name-json-web-tokens-jwt" class="internal xref">JSON Web Tokens (JWT)</a></p>
</li>
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.4">
<p id="section-toc.1-1.3.2.4.1"><a href="#section-3.4" class="auto internal xref">3.4</a>. <a href="#name-token-lifetimes" class="internal xref">Token Lifetimes</a></p>
</li>
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.5">
<p id="section-toc.1-1.3.2.5.1"><a href="#section-3.5" class="auto internal xref">3.5</a>. <a href="#name-scopes" class="internal xref">Scopes</a></p>
</li>
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.6">
<p id="section-toc.1-1.3.2.6.1"><a href="#section-3.6" class="auto internal xref">3.6</a>. <a href="#name-connections-between-authori" class="internal xref">Connections Between Authorization Servers and Protected Resources</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.6.2.1">
<p id="section-toc.1-1.3.2.6.2.1.1"><a href="#section-3.6.1" class="auto internal xref">3.6.1</a>. <a href="#name-introspection" class="internal xref">Introspection</a></p>
</li>
</ul>
</li>
</ul>
</li>
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4">
<p id="section-toc.1-1.4.1"><a href="#section-4" class="auto internal xref">4</a>. <a href="#name-protected-resource-profile" class="internal xref">Protected Resource Profile</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.1">
<p id="section-toc.1-1.4.2.1.1"><a href="#section-4.1" class="auto internal xref">4.1</a>. <a href="#name-connections-with-clients-2" class="internal xref">Connections with Clients</a></p>
</li>
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.2">
<p id="section-toc.1-1.4.2.2.1"><a href="#section-4.2" class="auto internal xref">4.2</a>. <a href="#name-protecting-resources" class="internal xref">Protecting Resources</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.2.2.1">
<p id="section-toc.1-1.4.2.2.2.1.1"><a href="#section-4.2.1" class="auto internal xref">4.2.1</a>. <a href="#name-trust-levels-and-scopes" class="internal xref">Trust Levels and Scopes</a></p>
</li>
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.2.2.2">
<p id="section-toc.1-1.4.2.2.2.2.1"><a href="#section-4.2.2" class="auto internal xref">4.2.2</a>. <a href="#name-trust-levels-example" class="internal xref">Trust Levels Example</a></p>
</li>
</ul>
</li>
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.3">
<p id="section-toc.1-1.4.2.3.1"><a href="#section-4.3" class="auto internal xref">4.3</a>. <a href="#name-connections-with-authorizat" class="internal xref">Connections with Authorization Servers</a></p>
</li>
</ul>
</li>
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5">
<p id="section-toc.1-1.5.1"><a href="#section-5" class="auto internal xref">5</a>. <a href="#name-security-considerations" class="internal xref">Security Considerations</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.1">
<p id="section-toc.1-1.5.2.1.1"><a href="#section-5.1" class="auto internal xref">5.1</a>. <a href="#name-dnssec-considerations" class="internal xref">DNSSEC Considerations</a></p>
</li>
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.2">
<p id="section-toc.1-1.5.2.2.1"><a href="#section-5.2" class="auto internal xref">5.2</a>. <a href="#name-best-practices" class="internal xref">Best Practices</a></p>
</li>
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.3">
<p id="section-toc.1-1.5.2.3.1"><a href="#section-5.3" class="auto internal xref">5.3</a>. <a href="#name-other-considerations" class="internal xref">Other Considerations</a></p>
</li>
</ul>
</li>
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6">
<p id="section-toc.1-1.6.1"><a href="#section-6" class="auto internal xref">6</a>. <a href="#name-privacy-considerations" class="internal xref">Privacy Considerations</a></p>
</li>
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.7">
<p id="section-toc.1-1.7.1"><a href="#section-7" class="auto internal xref">7</a>. <a href="#name-normative-references" class="internal xref">Normative References</a></p>
</li>
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8">
<p id="section-toc.1-1.8.1"><a href="#appendix-A" class="auto internal xref">Appendix A</a>. <a href="#name-acknowledgements" class="internal xref">Acknowledgements</a></p>
</li>
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.9">
<p id="section-toc.1-1.9.1"><a href="#appendix-B" class="auto internal xref">Appendix B</a>. <a href="#name-notices" class="internal xref">Notices</a></p>
</li>
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.10">
<p id="section-toc.1-1.10.1"><a href="#appendix-C" class="auto internal xref">Appendix C</a>. <a href="#name-document-history" class="internal xref">Document History</a></p>
</li>
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.11">
<p id="section-toc.1-1.11.1"><a href="#appendix-D" class="auto internal xref"></a><a href="#name-authors-addresses" class="internal xref">Authors' Addresses</a></p>
</li>
</ul>
</nav>
</section>
</div>
<div id="Introduction">
<section id="section-1">
<h2 id="name-introduction">
<a href="#section-1" class="section-number selfRef">1. </a><a href="#name-introduction" class="section-name selfRef">Introduction</a>
</h2>
<p id="section-1-1">This document profiles the OAuth 2.0 web authorization framework
for
use in the context of securing web-facing application programming
interfaces (APIs), particularly Representational State Transfer
(RESTful) APIs. The OAuth 2.0 specifications accommodate a wide
range of
implementations with varying security and usability
considerations,
across different types of software clients. The OAuth
2.0 client,
protected resource, and
authorization server profiles
defined in this document serve two
purposes:<a href="#section-1-1" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal type-1" id="section-1-2">
<li id="section-1-2.1">
<p id="section-1-2.1.1">Define a mandatory baseline set of security controls suitable
for
a wide range of government use cases, while maintaining
reasonable
ease of
implementation and functionality<a href="#section-1-2.1.1" class="pilcrow">¶</a></p>
</li>
<li id="section-1-2.2">
<p id="section-1-2.2.1">Identify optional, advanced security controls for sensitive use
cases where increased risk justifies more stringent controls.<a href="#section-1-2.2.1" class="pilcrow">¶</a></p>
</li>
</ol>
<div id="rnc">
<section id="section-1.1">
<h3 id="name-requirements-notation-and-c">
<a href="#section-1.1" class="section-number selfRef">1.1. </a><a href="#name-requirements-notation-and-c" class="section-name selfRef">Requirements Notation and Conventions</a>
</h3>
<p id="section-1.1-1">
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
<span><a href="#RFC2119" class="internal xref">RFC 2119</a> [<a href="#RFC2119" class="cite xref">RFC2119</a>]</span>
.<a href="#section-1.1-1" class="pilcrow">¶</a></p>
<p id="section-1.1-2">
All uses of
<span><a href="#RFC7515" class="internal xref">JSON Web Signature (JWS)</a> [<a href="#RFC7515" class="cite xref">RFC7515</a>]</span>
and
<span><a href="#RFC7516" class="internal xref">JSON Web Encryption (JWE)</a> [<a href="#RFC7516" class="cite xref">RFC7516</a>]</span>
data
structures in this specification utilize the JWS Compact
Serialization
or the JWE Compact Serialization; the JWS JSON
Serialization and the
JWE JSON Serialization are not used.<a href="#section-1.1-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="Terminology">
<section id="section-1.2">
<h3 id="name-terminology">
<a href="#section-1.2" class="section-number selfRef">1.2. </a><a href="#name-terminology" class="section-name selfRef">Terminology</a>
</h3>
<p id="section-1.2-1">
This specification uses the terms "Access Token", "Authorization
Code", "Authorization Endpoint", "Authorization Grant",
"Authorization
Server", "Client", "Client Authentication", "Client
Identifier",
"Client Secret", "Grant Type", "Protected Resource",
"Redirection
URI", "Refresh Token", "Resource Owner", "Resource
Server", "Response
Type", and "Token Endpoint" defined by
<span><a href="#RFC6749" class="internal xref">OAuth
2.0</a> [<a href="#RFC6749" class="cite xref">RFC6749</a>]</span>
, the terms "Claim Name", "Claim Value", and "JSON Web Token
(JWT)"
defined by
<span><a href="#RFC7519" class="internal xref">JSON Web Token (JWT)</a> [<a href="#RFC7519" class="cite xref">RFC7519</a>]</span>
,
and the terms defined by
<span><a href="#OpenID.Core" class="internal xref">OpenID Connect
Core 1.0</a> [<a href="#OpenID.Core" class="cite xref">OpenID.Core</a>]</span>
.<a href="#section-1.2-1" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-1.3">
<h3 id="name-conformance">
<a href="#section-1.3" class="section-number selfRef">1.3. </a><a href="#name-conformance" class="section-name selfRef">Conformance</a>
</h3>
<p id="section-1.3-1">This specification defines requirements for the following
components:<a href="#section-1.3-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-1.3-2.1">
<p id="section-1.3-2.1.1">OAuth 2.0 clients.<a href="#section-1.3-2.1.1" class="pilcrow">¶</a></p>
</li>
<li class="normal" id="section-1.3-2.2">
<p id="section-1.3-2.2.1">OAuth 2.0 authorization servers.<a href="#section-1.3-2.2.1" class="pilcrow">¶</a></p>
</li>
<li class="normal" id="section-1.3-2.3">
<p id="section-1.3-2.3.1">OAuth 2.0 protected resources.<a href="#section-1.3-2.3.1" class="pilcrow">¶</a></p>
</li>
</ul>
<p id="section-1.3-3">The specification also defines features for interaction between
these components:<a href="#section-1.3-3" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-1.3-4.1">
<p id="section-1.3-4.1.1">Client to authorization server.<a href="#section-1.3-4.1.1" class="pilcrow">¶</a></p>
</li>
<li class="normal" id="section-1.3-4.2">
<p id="section-1.3-4.2.1">Protected resource to authorization server.<a href="#section-1.3-4.2.1" class="pilcrow">¶</a></p>
</li>
</ul>
<p id="section-1.3-5">When an iGov-compliant component is interacting with other
iGov-compliant components, in any valid combination, all components
MUST fully conform to the features and requirements of this
specification. All interaction with non-iGov components is outside
the scope of this specification.<a href="#section-1.3-5" class="pilcrow">¶</a></p>
<p id="section-1.3-6">An iGov-compliant OAuth 2.0 authorization server MUST support all
features as described in this specification. A general-purpose
authorization server MAY support additional features for use with
non-iGov clients and protected resources.<a href="#section-1.3-6" class="pilcrow">¶</a></p>
<p id="section-1.3-7">An iGov-compliant OAuth 2.0 client MUST use all functions as
described in this specification. A general-purpose client library
MAY
support additional features for use with non-iGov authorization
servers and protected resources.<a href="#section-1.3-7" class="pilcrow">¶</a></p>
<p id="section-1.3-8">An iGov-compliant OAuth 2.0 protected resource MUST use all
functions as described in this specification. A general-purpose
protected resource library MAY support additional features for use
with non-iGov authorization servers and clients.<a href="#section-1.3-8" class="pilcrow">¶</a></p>
</section>
<section id="section-1.4">
<h3 id="name-global-requirements">
<a href="#section-1.4" class="section-number selfRef">1.4. </a><a href="#name-global-requirements" class="section-name selfRef">Global Requirements</a>
</h3>
<p id="section-1.4-1">All network connections MUST be made using TLS 1.3 or above.
Each originator of a TLS connection MUST verify the destination's certificate.
Additionally, the following four TLS 1.2 cipher suites MAY be used:<a href="#section-1.4-1" class="pilcrow">¶</a></p>
<ul class="normal ulEmpty">
<li class="normal ulEmpty" id="section-1.4-2.1">
<p id="section-1.4-2.1.1">TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256<a href="#section-1.4-2.1.1" class="pilcrow">¶</a></p>
</li>
<li class="normal ulEmpty" id="section-1.4-2.2">
<p id="section-1.4-2.2.1">TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384<a href="#section-1.4-2.2.1" class="pilcrow">¶</a></p>
</li>
<li class="normal ulEmpty" id="section-1.4-2.3">
<p id="section-1.4-2.3.1">TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256<a href="#section-1.4-2.3.1" class="pilcrow">¶</a></p>
</li>
<li class="normal ulEmpty" id="section-1.4-2.4">
<p id="section-1.4-2.4.1">TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384<a href="#section-1.4-2.4.1" class="pilcrow">¶</a></p>
</li>
</ul>
<p id="section-1.4-3">Implementers of this profile SHOULD monitor the progress of specifications of post-quantum
cryptography for TLS implementations.
Implementers MAY adopt a cipher suite not included in <span><a href="#BCP195" class="internal xref">BCP195</a> [<a href="#BCP195" class="cite xref">BCP195</a>]</span> when post quantum safety
is required if the cipher suite is supported in the implementation environment.<a href="#section-1.4-3" class="pilcrow">¶</a></p>
<p id="section-1.4-4">An example of an emerging PQ cipher suite that is broadly supported at the time of writing is X25519MLKEM768, specified by
<span><a href="#mlkem.ikev2" class="internal xref">Post-quantum Hybrid Key Exchange with ML-KEM in the Internet Key Exchange Protocol Version 2 (IKEv2)</a> [<a href="#mlkem.ikev2" class="cite xref">mlkem.ikev2</a>]</span>.<a href="#section-1.4-4" class="pilcrow">¶</a></p>
<p id="section-1.4-5">
For the authorization_endpoint, the authorization server MAY allow
additional cipher suites that are permitted by the latest version of <span><a href="#BCP195" class="internal xref">BCP195</a> [<a href="#BCP195" class="cite xref">BCP195</a>]</span>,
if necessary to allow sufficient interoperability with users' web browsers or as required by local regulations.<a href="#section-1.4-5" class="pilcrow">¶</a></p>
<p id="section-1.4-6">
NOTE: Permitted cipher suites are those listed in <span><a href="#BCP195" class="internal xref">BCP195</a> [<a href="#BCP195" class="cite xref">BCP195</a>]</span> that do not explicitly say MUST NOT use.<a href="#section-1.4-6" class="pilcrow">¶</a></p>
<p id="section-1.4-7">Endpoints for use by web browsers MUST use mechanisms to ensure that connections cannot be downgraded
using TLS Stripping attacks. Protected resources MAY implement an HTTP Strict Transport Security policy as defined in
<span><a href="#RFC6797" class="internal xref">HTTP Strict Transport Security (HSTS)</a> [<a href="#RFC6797" class="cite xref">RFC6797</a>]</span> to mitigate these attacks. Protected resources SHOULD
consider registering web domain names with browsers that offer browser-side ("preload") HSTS policy enforcement to further mitigate
TLS downgrade attacks.<a href="#section-1.4-7" class="pilcrow">¶</a></p>
</section>
</section>
</div>
<div id="ClientProfiles">
<section id="section-2">
<h2 id="name-client-profiles">
<a href="#section-2" class="section-number selfRef">2. </a><a href="#name-client-profiles" class="section-name selfRef">Client Profiles</a>
</h2>
<p id="section-2-1"></p>
<div id="ClientTypes">
<section id="section-2.1">
<h3 id="name-client-types">
<a href="#section-2.1" class="section-number selfRef">2.1. </a><a href="#name-client-types" class="section-name selfRef">Client Types</a>
</h3>
<p id="section-2.1-1">
OAuth defines two client types, based on their ability to
authenticate securely with the authorization server<a href="#section-2.1-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-2.1-2">
<dt id="section-2.1-2.1">confidential clients:</dt>
<dd style="margin-left: 1.5em" id="section-2.1-2.2">Clients that have credentials with the authorization server.<a href="#section-2.1-2.2" class="pilcrow">¶</a>
</dd>
<dd class="break"></dd>
<dt id="section-2.1-2.3">public clients:</dt>
<dd style="margin-left: 1.5em" id="section-2.1-2.4">Clients without credentials.<a href="#section-2.1-2.4" class="pilcrow">¶</a>
</dd>
<dd class="break"></dd>
</dl>
</section>
</div>
<div id="UseCases">
<section id="section-2.2">
<h3 id="name-client-type-use-cases">
<a href="#section-2.2" class="section-number selfRef">2.2. </a><a href="#name-client-type-use-cases" class="section-name selfRef">Client Type Use Cases</a>
</h3>
<p id="section-2.2-1">This specification has been designed around the following client use cases:<a href="#section-2.2-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-2.2-2">
<dt id="section-2.2-2.1">web application:</dt>
<dd style="margin-left: 1.5em" id="section-2.2-2.2">A web application is a client running on a web
server. Resource owners access the client via an HTML user
interface rendered in a user agent on the device used by the
resource owner. The client credentials as well as any access
tokens issued to the client are stored on the web server and are
not exposed to or accessible by the resource owner. In this use case, web applications are confidential clients.<a href="#section-2.2-2.2" class="pilcrow">¶</a>
</dd>
<dd class="break"></dd>
<dt id="section-2.2-2.3">native application:</dt>
<dd style="margin-left: 1.5em" id="section-2.2-2.4">A native application is a client installed and
executed on the device used by the resource owner. Protocol data
and credentials are accessible to the resource owner. It is
assumed that any client authentication credentials included in the
application can be extracted. Dynamically issued access tokens
and refresh tokens can receive an acceptable level of protection.
On some platforms, these credentials are protected from other
applications residing on the same device. Best current practices for native applications are detailed in
<span><a href="#RFC8252" class="internal xref">OAuth 2.0 for Native Apps</a> [<a href="#RFC8252" class="cite xref">RFC8252</a>]</span>. In this use case, native applications are public clients.<a href="#section-2.2-2.4" class="pilcrow">¶</a>
</dd>
<dd class="break"></dd>
<dt id="section-2.2-2.5">browser-based application:</dt>
<dd style="margin-left: 1.5em" id="section-2.2-2.6">A browser-based application is a client
in which the client code is downloaded from a web server and
executes within a user agent (e.g., web browser) on the device
used by the resource owner. Protocol data and credentials are
easily accessible (and often visible) to the resource owner. If
such applications wish to use client credentials, it is
recommended to utilize the backend for frontend pattern. Since
such applications reside within the user agent, they can make
seamless use of the user agent capabilities when requesting
authorization. This use case is out of scope due to the inherent lack of security provided by browser-based applications.
However, best current practices are detailed in <span><a href="#browser-based-apps" class="internal xref">OAuth 2.0 for Browser-Based Applications</a> [<a href="#browser-based-apps" class="cite xref">browser-based-apps</a>]</span>.<a href="#section-2.2-2.6" class="pilcrow">¶</a>
</dd>
<dd class="break"></dd>
</dl>
</section>
</div>
<div id="ClientRegistration">
<section id="section-2.3">
<h3 id="name-client-registration">
<a href="#section-2.3" class="section-number selfRef">2.3. </a><a href="#name-client-registration" class="section-name selfRef">Client Registration</a>
</h3>
<p id="section-2.3-1">All clients MUST register with the authorization server. For
client software that may be installed on multiple client
instances,
such as native applications,
each client instance MAY receive a unique client identifier from
the authorization server.<a href="#section-2.3-1" class="pilcrow">¶</a></p>
<p id="section-2.3-2">Client registration MAY be completed by either out-of-band configuration or using the <span><a href="#RFC7591" class="internal xref">Dynamic Client Registration Protocol</a> [<a href="#RFC7591" class="cite xref">RFC7591</a>]</span>.<a href="#section-2.3-2" class="pilcrow">¶</a></p>
<p id="section-2.3-3"> If a client uses <span><a href="#RFC8705" class="internal xref">mTLS</a> [<a href="#RFC8705" class="cite xref">RFC8705</a>]</span> for client authentication or to sender-constrain tokens, the client MUST include the
tls_client_certificate_bound_access_tokens parameter in its registration metadata.<a href="#section-2.3-3" class="pilcrow">¶</a></p>
<p id="section-2.3-4"> If a client uses <span><a href="#RFC9449" class="internal xref">DPoP</a> [<a href="#RFC9449" class="cite xref">RFC9449</a>]</span> to sender constrain tokens, the client MUST include the dpop_bound_access_tokens parameter
in its registration metadata.<a href="#section-2.3-4" class="pilcrow">¶</a></p>
<p id="section-2.3-5">Clients using mTLS for client authentication or to sender-constrain tokens MUST register their TLS certificate's subject DN with the
authorization server.
Clients using self-signed certificate option are not guaranteed uniqueness of their certificate fingerprint.<a href="#section-2.3-5" class="pilcrow">¶</a></p>
<div id="RedirectURI">
<section id="section-2.3.1">
<h4 id="name-redirect-uri">
<a href="#section-2.3.1" class="section-number selfRef">2.3.1. </a><a href="#name-redirect-uri" class="section-name selfRef">Redirect URI</a>
</h4>
<p id="section-2.3.1-1">Clients using the authorization code grant type
MUST register
their full redirect URIs.<a href="#section-2.3.1-1" class="pilcrow">¶</a></p>
<p id="section-2.3.1-2">Clients MUST protect the values passed back to its redirect
URI by ensuring that the redirect URI is one of the following:<a href="#section-2.3.1-2" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-2.3.1-3.1">
<p id="section-2.3.1-3.1.1">Hosted on a website with Transport Layer Security (TLS)
protection (a Hypertext Transfer Protocol - Secure
(HTTPS) URI)<a href="#section-2.3.1-3.1.1" class="pilcrow">¶</a></p>
</li>
<li class="normal" id="section-2.3.1-3.2">
<p id="section-2.3.1-3.2.1">Hosted on a client-specific non-remote-protocol URI scheme
(e.g., myapp://)<a href="#section-2.3.1-3.2.1" class="pilcrow">¶</a></p>
</li>
</ul>
<p id="section-2.3.1-4">Clients MUST use a unique redirect URI for each logical authorization server.<a href="#section-2.3.1-4" class="pilcrow">¶</a></p>
<p id="section-2.3.1-5">Clients MUST NOT forward values passed back to their redirect
URIs to other arbitrary or user-provided URIs (a practice known as an "open redirector").<a href="#section-2.3.1-5" class="pilcrow">¶</a></p>
<p id="section-2.3.1-6">Refer to <span><a href="#BCP240" class="internal xref">Best Current Practice for OAuth 2.0 Security</a> [<a href="#BCP240" class="cite xref">BCP240</a>]</span> Section 2.4.1
for additional guidance on implementation of edge cases.<a href="#section-2.3.1-6" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="PoPTokens">
<section id="section-2.4">
<h3 id="name-sender-constrained-tokens">
<a href="#section-2.4" class="section-number selfRef">2.4. </a><a href="#name-sender-constrained-tokens" class="section-name selfRef">Sender-constrained Tokens</a>
</h3>
<p id="section-2.4-1"> While a bearer token can be used by anyone in possession of the token, a sender-constrained token is
bound to a particular symmetric or asymmetric key issued to, or already possessed by, the client.
The association of the key to the token is also communicated to the protected resource. When the client
presents the token to the protected resource, it is also required to demonstrate possession of the corresponding key.<a href="#section-2.4-1" class="pilcrow">¶</a></p>
<p id="section-2.4-2">As described in <span><a href="#BCP240" class="internal xref">Best Current Practice for OAuth 2.0 Security</a> [<a href="#BCP240" class="cite xref">BCP240</a>]</span>, sender-constrained tokens could
prevent a number of attacks on OAuth that entail the misuse of stolen and leaked access tokens by unauthorized parties.
The attacker would need to obtain the legitimate client's cryptographic key along with the access
token to gain access to protected resources.<a href="#section-2.4-2" class="pilcrow">¶</a></p>
<p id="section-2.4-3"> All clients MUST use proof of possession to sender-constrain access tokens using either <span><a href="#RFC8705" class="internal xref">OAuth 2.0 Mutual-TLS
Client Authentication and Certificate-Bound Access Tokens</a> [<a href="#RFC8705" class="cite xref">RFC8705</a>]</span> or
<span><a href="#RFC9449" class="internal xref">OAuth 2.0 Demonstrating Proof of Possession (DPoP)</a> [<a href="#RFC9449" class="cite xref">RFC9449</a>]</span>.<a href="#section-2.4-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="AuthNContext">
<section id="section-2.5">
<h3 id="name-authentication-context-and-">
<a href="#section-2.5" class="section-number selfRef">2.5. </a><a href="#name-authentication-context-and-" class="section-name selfRef">Authentication Context and Step-Up Authentication Challenge Protocol Support</a>
</h3>
<p id="section-2.5-1">Clients MUST support the mechanism specified in <span><a href="#RFC9470" class="internal xref">OAuth 2.0 Step Up Authentication Challenge
Protocol"</a> [<a href="#RFC9470" class="cite xref">RFC9470</a>]</span> to communicate authentication context and implement interoperable step up authentication.<a href="#section-2.5-1" class="pilcrow">¶</a></p>
<p id="section-2.5-2">This profile acknowledges government use cases will likely operate within an ecosystem of authentication methods of highly variable security
value for the foreseeable future by imposing requirements to enable protected resources with basic capabilities to communicate
requirements for authentication strength and recency to supporting authorization clients and servers, as well as the capability to enforce access
policies using access tokens augmented with the strength and recency of the authentication event that led to the issuance of each specific access token.<a href="#section-2.5-2" class="pilcrow">¶</a></p>
<p id="section-2.5-3">This profile leverages the supporting server metadata, request, token claims and values, and error messages from <span><a href="#RFC9470" class="internal xref">OAuth 2.0
Step Up Authentication Challenge
Protocol</a> [<a href="#RFC9470" class="cite xref">RFC9470</a>]</span> and <span><a href="#OpenID.Core" class="internal xref">OpenID Connect Core 1.0</a> [<a href="#OpenID.Core" class="cite xref">OpenID.Core</a>]</span>.<a href="#section-2.5-3" class="pilcrow">¶</a></p>
<p id="section-2.5-4">Digital identity policies and semantic mappings to string values are necessary for implementation but are out of scope for this profile.<a href="#section-2.5-4" class="pilcrow">¶</a></p>
<p id="section-2.5-5">OAuth 2.0 MUST NOT be used as an authentication protocol. Use of the <span><a href="#OpenID.iGov" class="internal xref">International Government Assurance Profile (iGov)
for OpenID Connect 1.0</a> [<a href="#OpenID.iGov" class="cite xref">OpenID.iGov</a>]</span> is RECOMMENDED to provide the identity
authentication layer for iGov OAuth 2.0 delegated access use cases.<a href="#section-2.5-5" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-2.6">
<h3 id="name-connection-to-the-authoriza">
<a href="#section-2.6" class="section-number selfRef">2.6. </a><a href="#name-connection-to-the-authoriza" class="section-name selfRef">Connection to the Authorization Server</a>
</h3>
<div id="RequestsToAuthorizationEndpoint">
<section id="section-2.6.1">
<h4 id="name-requests-to-the-authorizati">
<a href="#section-2.6.1" class="section-number selfRef">2.6.1. </a><a href="#name-requests-to-the-authorizati" class="section-name selfRef">Requests to the Authorization Endpoint</a>
</h4>
<p id="section-2.6.1-1">All clients MUST use the PKCE S256 code challenge method as described in
<span><a href="#RFC7636" class="internal xref">Proof Key for Code Exchange by OAuth Public Clients</a> [<a href="#RFC7636" class="cite xref">RFC7636</a>]</span> and
include the "code_challenge" parameter
and "code_challenge_method", set to "S256", in the authorization request.<a href="#section-2.6.1-1" class="pilcrow">¶</a></p>
<p id="section-2.6.1-2">
Clients making a request to the
authorization endpoint MUST use an unpredictable value for the
state
parameter with at least 128 bits of entropy. Clients MUST
validate
the value of the
<code>state</code>
parameter upon
return to the redirect URI and MUST ensure that the
state value is
securely tied to the user's current session
(e.g., by
relating
the state value to a session identifier issued by
the client
software to the browser).<a href="#section-2.6.1-2" class="pilcrow">¶</a></p>
<p id="section-2.6.1-3">Clients MUST include their full redirect URI in the
authorization request.<a href="#section-2.6.1-3" class="pilcrow">¶</a></p>
<p id="section-2.6.1-4">The client MAY specify a strength of authentication and maximum age to the authorization server that should be met
when issuing an access token for the requesting client by including parameters in the authorization request:<a href="#section-2.6.1-4" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-2.6.1-5">
<dt id="section-2.6.1-5.1">acr_values</dt>
<dd style="margin-left: 1.5em" id="section-2.6.1-5.2"> a space-separated string listing the authentication context class reference values in order of preference.
The protected resource requires one of these values for the authentication event associated with the access token. As defined
in Section 1.2 of <span><a href="#OpenID.Core" class="internal xref">OpenID Connect Core 1.0</a> [<a href="#OpenID.Core" class="cite xref">OpenID.Core</a>]</span>, the authentication context conveys information about how
authentication takes place (e.g., what authentication
method(s) or assurance level to meet). It is out of scope of this document to determine how an organization semantically maps their
digital identity practices to acr values that identify levels of assurance.<a href="#section-2.6.1-5.2" class="pilcrow">¶</a>
</dd>
<dd class="break"></dd>
<dt id="section-2.6.1-5.3">max_age</dt>
<dd style="margin-left: 1.5em" id="section-2.6.1-5.4"> a non-negative integer value that indicates the allowable elapsed time in seconds since the last active authentication event
associated with the access token.<a href="#section-2.6.1-5.4" class="pilcrow">¶</a>
</dd>
<dd class="break"></dd>
</dl>
<p id="section-2.6.1-6">Furthermore, if the authorization request is a follow-up to a prior request that did not meet the resource server's initial or subsequent
authentication strength or recency requirements, the client should include the acr_values and/or max_age values sent by the resource server with
the insuffient_user_authentication error code that specify expected strength and recency requirements to be provided to the authentication provider,
such as the OpenID Provider, in a new authentication request.<a href="#section-2.6.1-6" class="pilcrow">¶</a></p>
<p id="section-2.6.1-7">The following is a sample response from a client to
the
end user's browser for the purpose of redirecting the end
user
to the authorization server's authorization endpoint:<a href="#section-2.6.1-7" class="pilcrow">¶</a></p>
<div class="alignLeft art-text artwork" id="section-2.6.1-8">
<pre>
NOTE: '\' line wrapping per RFC 8792
HTTP/1.2 302 Found
Cache-Control: no-cache
Connection: close
Content-Type: text/plain; charset=UTF-8
Date: Wed, 07 Jan 2015 20:24:15 GMT
Location: \
https://idp-p.example.com/authorize?client_id=55f9f559-2496-49d4-b\
6c3-351a586b7484&response_type=code&scope=openid+email&redirect_uri=\
https%3A%2F%2Fclient.example.org%2Fcb&acr_values=myACR&max_age=1800\
Status: 302 Found
</pre><a href="#section-2.6.1-8" class="pilcrow">¶</a>
</div>
<p id="section-2.6.1-9">This causes the browser to send the following (non-normative) request to the
authorization endpoint (inline wraps for display purposes only):<a href="#section-2.6.1-9" class="pilcrow">¶</a></p>
<div class="alignLeft art-text artwork" id="section-2.6.1-10">
<pre>
NOTE: '\' line wrapping per RFC 8792
GET /authorize?
client_id=55f9f559-2496-49d4-b6c3-351a586b7484
&nonce=cd567ed4d958042f721a7cdca557c30d
&response_type=code
&scope=openid+email
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb HTTP/1.1
Host: idp-p.example.com
</pre><a href="#section-2.6.1-10" class="pilcrow">¶</a>
</div>
</section>
</div>
<div id="RequestsToTokenEndpoint">
<section id="section-2.6.2">
<h4 id="name-requests-to-the-token-endpo">
<a href="#section-2.6.2" class="section-number selfRef">2.6.2. </a><a href="#name-requests-to-the-token-endpo" class="section-name selfRef">Requests to the Token Endpoint</a>
</h4>
<p id="section-2.6.2-1">
Confidential clients MUST
authenticate to the authorization server's token endpoint using either
the private_key_jwt method as defined in
<span><a href="#OpenID.Core" class="internal xref">OpenID Connect Core</a> [<a href="#OpenID.Core" class="cite xref">OpenID.Core</a>]</span>
or
the mutually-authenticated transport layer security (mTLS) request method
defined in
<span><a href="#RFC8705" class="internal xref">OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens</a> [<a href="#RFC8705" class="cite xref">RFC8705</a>]</span>.<a href="#section-2.6.2-1" class="pilcrow">¶</a></p>
<p id="section-2.6.2-2">If using the private_key_jwt method, the request MUST be a JWT assertion as defined by the
<span><a href="#RFC7523" class="internal xref">JWT Profile for OAuth 2.0 Client Authentication and Authorization Grants</a> [<a href="#RFC7523" class="cite xref">RFC7523</a>]</span>. The JWT assertion MUST be signed
by the client using the client's private key.
If using <span><a href="#RFC8705" class="internal xref">mTLS</a> [<a href="#RFC8705" class="cite xref">RFC8705</a>]</span>, the request MUST be made over a mutually authenticated TLS channel.<a href="#section-2.6.2-2" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-2.6.3">
<h4 id="name-client-keys">
<a href="#section-2.6.3" class="section-number selfRef">2.6.3. </a><a href="#name-client-keys" class="section-name selfRef">Client Keys</a>
</h4>
<p id="section-2.6.3-1">
Confidential clients MUST have a
public/private key pair for use in authentication to the token
endpoint. These clients MUST either send the public key
directly in the
<code>jwks</code>
field or
register a
<code>jwks_uri</code>
that is
reachable by the authorization server. It is
RECOMMENDED that
clients use a
<code>jwks_uri</code>
if possible as
this allows for key rotation more easily. This applies to both
dynamic and out-of-band client registration.<a href="#section-2.6.3-1" class="pilcrow">¶</a></p>
<p id="section-2.6.3-2">
The
<code>jwks</code>
field or the content
available from the
<code>jwks_uri</code>
of a client
MUST contain a public key in
<span><a href="#RFC7517" class="internal xref">JSON Web Key Set
(JWK Set)</a> [<a href="#RFC7517" class="cite xref">RFC7517</a>]</span>
format. The authorization server MUST validate the
content of the
client's registered jwks_uri document and verify that
it contains a
JWK Set. The following example is of a 2048-bit RSA
key:<a href="#section-2.6.3-2" class="pilcrow">¶</a></p>
<div class="alignLeft art-text artwork" id="section-2.6.3-3">
<pre>
NOTE: '\' line wrapping per RFC 8792
{
"keys": [
{
"alg": "RS256",
"e": "AQAB",
"n": "kAMYD62n_f2rUcR4awJX4uccDt0zcXRssq_mDch5-ifcShx9aTtTVza2\
3PTn3KaKrsBXwWcfioXR6zQn5eYdZQVGNBfOR4rxF5i7t3hfb4WkS50EK1gBYk2lO9NS\
rQ-xG9QsUsAnN6RHksXqsdOqv-nxjLexDfIJlgbcCN9h6TB-C66ZXv7PVhl19gIYVifS\
U7liHkLe0l0fw7jUI6rHLHf4d96_neR1HrNIK_xssr99Xpv1EM_ubxpktX0T925-qej9\
fMEpzzQ5HLmcNt1H2_VQ_Ww1JOLn9vRn-H48FDj7TxlIT74XdTZgTv31w_GRPAOfyxEw\
_ZUmxhz5Z-gTlQ",
"kty": "RSA",
"kid": "oauth-client"
}
]
}
</pre><a href="#section-2.6.3-3" class="pilcrow">¶</a>
</div>
<p id="section-2.6.3-4">For reference, the corresponding public/private key pair for
this
public key is the following (in JWK format):<a href="#section-2.6.3-4" class="pilcrow">¶</a></p>
<div class="alignLeft art-text artwork" id="section-2.6.3-5">
<pre>
NOTE: '\' line wrapping per RFC 8792
{
"alg": "RS256",
"d": "PjIX4i2NsBQuOVIw74ZDjqthYsoFvaoah9GP-cPrai5s5VUIlLoadEAdGbBr\
ss_6dR58x_pRlPHWh04vLQsFBuwQNc9SN3O6TAaai9Jg5TlCi6V0d4O6lUoTYpMR0cxF\
IU-xFMwII--_OZRgmAxiYiAXQj7TKMKvgSvVO7-9-YdhMwHoD-UrJkfnZckMKSs0BoAb\
jReTski3IV9f1wVJ53_pmr9NBpiZeHYmmG_1QDSbBuY35Zummut4QShF-fey2gSALdp9\
h9hRk1p1fsTZtH2lwpvmOcjwDkSDv-zO-4Pt8NuOyqNVPFahROBPlsMVxc_zjPck8ltb\
lalBHPo6AQ",
"e": "AQAB",
"n": "kAMYD62n_f2rUcR4awJX4uccDt0zcXRssq_mDch5-ifcShx9aTtTVza23PTn\
3KaKrsBXwWcfioXR6zQn5eYdZQVGNBfOR4rxF5i7t3hfb4WkS50EK1gBYk2lO9NSrQ-x\
G9QsUsAnN6RHksXqsdOqv-nxjLexDfIJlgbcCN9h6TB-C66ZXv7PVhl19gIYVifSU7li\
HkLe0l0fw7jUI6rHLHf4d96_neR1HrNIK_xssr99Xpv1EM_ubxpktX0T925-qej9fMEp\
zzQ5HLmcNt1H2_VQ_Ww1JOLn9vRn-H48FDj7TxlIT74XdTZgTv31w_GRPAOfyxEw_ZUm\
xhz5Z-gTlQ",
"kty": "RSA",
"kid": "oauth-client"
}
</pre><a href="#section-2.6.3-5" class="pilcrow">¶</a>
</div>
<p id="section-2.6.3-6">Note that the second example contains both the public and
private
keys, while the first example contains the public key only.<a href="#section-2.6.3-6" class="pilcrow">¶</a></p>
</section>
</section>
<section id="section-2.7">
<h3 id="name-connection-to-the-protected">
<a href="#section-2.7" class="section-number selfRef">2.7. </a><a href="#name-connection-to-the-protected" class="section-name selfRef">Connection to the Protected Resource</a>
</h3>
<div id="RequestsToProtectedResource">
<section id="section-2.7.1">
<h4 id="name-requests-to-the-protected-r">
<a href="#section-2.7.1" class="section-number selfRef">2.7.1. </a><a href="#name-requests-to-the-protected-r" class="section-name selfRef">Requests to the Protected Resource</a>
</h4>
<p id="section-2.7.1-1">
Clients MUST use the authorization request header field mechanism to send bearer tokens as defined by
<span>[<a href="#RFC6750" class="cite xref">RFC6750</a>]</span>.<a href="#section-2.7.1-1" class="pilcrow">¶</a></p>
<p id="section-2.7.1-2">An example of an OAuth-protected call to the OpenID Connect
UserInfo endpoint, sending the token in the Authorization header,
follows:<a href="#section-2.7.1-2" class="pilcrow">¶</a></p>
<div class="alignLeft art-text artwork" id="section-2.7.1-3">
<pre>
NOTE: '\' line wrapping per RFC 8792
GET /userinfo HTTP/1.1
Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.eyJleHAiOjE0MTg3MDI0MTIsI\
\mF1ZCI6WyJjMWJjODRlNC00N2VlLTRiNjQtYmI1Mi01Y2RhNmM4MWY3ODgiXSwiaXNz\
IjoiaHR0cHM6XC9cL2lkcC1wLmV4YW1wbGUuY29tXC8iLCJqdGkiOiJkM2Y3YjQ4Zi1i\
YzgxLTQwZWMtYTE0MC05NzRhZjc0YzRkZTMiLCJpYXQiOjE0MTg2OTg4MTJ9.iHMz_tz\
Z90_b0QZS-AXtQtvclZ7M4uDAs1WxCFxpgBfBanolW37X8h1ECrUJexbXMD6rrj_uuWE\
qPD738oWRo0rOnoKJAgbF1GhXPAYnN5pZRygWSD1a6RcmN85SxUig0H0e7drmdmRkPQg\
bl2wMhu-6h2Oqize4dKmykN9UX_2drXrooSxpRZqFVYX8PkCvCCBuFy2O-HPRov_SwtJ\
Mk5qjUWMyn2I4Nu2s-R20aCA-7T5dunr0iWCkLQnVnaXMfA22RlRiU87nl21zappYb1_\
EHF9ePyq3Q353cDUY7vje8m2kKXYTgc_bUAYuW-W3SMSw5UlKa
</pre><a href="#section-2.7.1-3" class="pilcrow">¶</a>
</div>
</section>
</div>
</section>
</section>
</div>
<div id="ServerProfile">
<section id="section-3">
<h2 id="name-authorization-server-profil">
<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-authorization-server-profil" class="section-name selfRef">Authorization Server Profile</a>
</h2>
<p id="section-3-1">
All servers MUST conform to applicable recommendations found in the
Security Considerations sections of
<span>[<a href="#RFC6749" class="cite xref">RFC6749</a>]</span>
and those
found in the
<span><a href="#RFC6819" class="internal xref">OAuth Threat Model
Document</a> [<a href="#RFC6819" class="cite xref">RFC6819</a>]</span>.<a href="#section-3-1" class="pilcrow">¶</a></p>
<p id="section-3-2">The authorization server MUST protect all communications to and
from
its OAuth endpoints using TLS as described in Section 1.4.<a href="#section-3-2" class="pilcrow">¶</a></p>
<section id="section-3.1">
<h3 id="name-connections-with-clients">
<a href="#section-3.1" class="section-number selfRef">3.1. </a><a href="#name-connections-with-clients" class="section-name selfRef">Connections with clients</a>
</h3>
<p id="section-3.1-1"></p>
<section id="section-3.1.1">
<h4 id="name-grant-types">
<a href="#section-3.1.1" class="section-number selfRef">3.1.1. </a><a href="#name-grant-types" class="section-name selfRef">Grant types</a>
</h4>
<p id="section-3.1.1-1">
Authorization servers MUST support the
<code>authorization_code</code> grant type and MAY support the
<code>client_credentials</code>
grant type. The implicit grant type MUST NOT be used.<a href="#section-3.1.1-1" class="pilcrow">¶</a></p>
<p id="section-3.1.1-2">Authorization servers MUST limit each registered client
(identified
by a client ID) to a single client type only, since a
single piece of
software will be functioning at runtime as only one client type. Clients that have
multiple client types MUST have a
separate client ID for each client type.<a href="#section-3.1.1-2" class="pilcrow">¶</a></p>
</section>
<section id="section-3.1.2">
<h4 id="name-client-authentication">
<a href="#section-3.1.2" class="section-number selfRef">3.1.2. </a><a href="#name-client-authentication" class="section-name selfRef">Client authentication</a>
</h4>
<p id="section-3.1.2-1">Authorization servers MUST enforce client authentication for confidential clients.
Public clients cannot authenticate to the authorization server.
The authorization server MUST support the RS256
signature method (the
Rivest, Shamir, and Adleman (RSA) signature
algorithm with a
256-bit
hash) and MAY use other asymmetric
signature methods listed in the
JSON Web Algorithms (<span><a href="#RFC7518" class="internal xref">JWA</a> [<a href="#RFC7518" class="cite xref">RFC7518</a>]</span>)
specification.<a href="#section-3.1.2-1" class="pilcrow">¶</a></p>
<p id="section-3.1.2-2"> The authorization server MUST validate all redirect
URIs for authorization code grant types.<a href="#section-3.1.2-2" class="pilcrow">¶</a></p>
<p id="section-3.1.2-3"> The authorization server MUST confirm thumbprints of client keys.<a href="#section-3.1.2-3" class="pilcrow">¶</a></p>
<p id="section-3.1.2-4"> Authorization servers MUST only grant access to higher level scope resources to
clients that have permission to request these scope levels. Authorization servers MUST reject client authorization requests
containing scopes that are outside their permission.<a href="#section-3.1.2-4" class="pilcrow">¶</a></p>
<p id="section-3.1.2-5">Authorization servers MAY set the expiry time (<code>exp</code>)
of access_tokens associated with higher level resources to be shorter than
access_tokens for less sensitive resources.<a href="#section-3.1.2-5" class="pilcrow">¶</a></p>
<p id="section-3.1.2-6">Authorization servers MAY allow a <code>refresh_token</code>
issued at a higher level to be
used to obtain an access_token for a lower level resource scope with an
extended expiry time. The client MUST request both the higher level scope and
lower level scope in the original authorization request. This allows clients to
continue accessing lower level resources after the higher level resource access
has expired -- without requiring an additional user authentication/authorization.<a href="#section-3.1.2-6" class="pilcrow">¶</a></p>
<p id="section-3.1.2-7">When a client requests both a higher level scope and a lower level scope in the original authorization request, Authorization
servers MAY allow refresh tokens issued at the higher level to be used to obtain an access_token for a lower level resource scope
with an extended expiry time. This allows clients to continue accessing lower level resources after the higher level resource
access has expired without requiring an additional user authentication/authorization.<a href="#section-3.1.2-7" class="pilcrow">¶</a></p>
</section>
<div id="DynamicRegistration">
<section id="section-3.1.3">
<h4 id="name-dynamic-registration">
<a href="#section-3.1.3" class="section-number selfRef">3.1.3. </a><a href="#name-dynamic-registration" class="section-name selfRef">Dynamic Registration</a>
</h4>
<p id="section-3.1.3-1">
Dynamic Registration allows for authorized Clients to on-board programmatically without administrative intervention.
This is particularly important in ecosystems with many potential Clients, including Mobile Apps acting as independent Clients.
Authorization servers MUST support dynamic client registration,
and clients MAY register using the
<span><a href="#RFC7591" class="internal xref">Dynamic
Client Registration Protocol</a> [<a href="#RFC7591" class="cite xref">RFC7591</a>]</span>
for authorization code grant types. Clients MUST NOT
dynamically
register for the
client credentials grant type.
Authorization
servers MAY limit the
scopes available to dynamically
registered
clients.<a href="#section-3.1.3-1" class="pilcrow">¶</a></p>
<p id="section-3.1.3-2"> Authorization
servers MAY protect their Dynamic Registration endpoints by requiring clients to present credentials that the authorization
server would recognize as authorized participants. Authorization servers MAY accept signed software statements as described
in <span>[<a href="#RFC7591" class="cite xref">RFC7591</a>]</span>
issued to client software developers from a
trusted registration
entity. The software statement can be used to
tie together many
instances of the same client software that will be
run, dynamically
registered, and authorized separately at runtime.
The software
statement MUST include the following client metadata
parameters:<a href="#section-3.1.3-2" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-3.1.3-3">
<dt id="section-3.1.3-3.1">redirect_uris</dt>
<dd style="margin-left: 1.5em" id="section-3.1.3-3.2">
array of redirect URIs used by the
client; subject to the
requirements listed in
<a href="#RedirectURI" class="auto internal xref">Section 2.3.1</a><a href="#section-3.1.3-3.2" class="pilcrow">¶</a>
</dd>
<dd class="break"></dd>
<dt id="section-3.1.3-3.3">grant_types</dt>
<dd style="margin-left: 1.5em" id="section-3.1.3-3.4">grant type used by the client; must be
"authorization_code" or "client_credentials"<a href="#section-3.1.3-3.4" class="pilcrow">¶</a>
</dd>
<dd class="break"></dd>
<dt id="section-3.1.3-3.5">client_name</dt>
<dd style="margin-left: 1.5em" id="section-3.1.3-3.6">human-readable name of the client<a href="#section-3.1.3-3.6" class="pilcrow">¶</a>
</dd>
<dd class="break"></dd>
<dt id="section-3.1.3-3.7">client_uri</dt>
<dd style="margin-left: 1.5em" id="section-3.1.3-3.8">URL of a web page containing further
information
about the client<a href="#section-3.1.3-3.8" class="pilcrow">¶</a>
</dd>
<dd class="break"></dd>
<dt id="section-3.1.3-3.9">tls_client_certificate_bound_access_tokens</dt>
<dd style="margin-left: 1.5em" id="section-3.1.3-3.10">
REQUIRED. Boolean value indicating server support for mutual-TLS client certificate-bound access tokens.<a href="#section-3.1.3-3.10" class="pilcrow">¶</a>
</dd>
<dd class="break"></dd>
<dt id="section-3.1.3-3.11">acr_values_supported</dt>
<dd style="margin-left: 1.5em" id="section-3.1.3-3.12">OPTIONAL. Indicates the client will include the acr_values and max_age
parameters in authorization requests, and send insufficient_user_authentication error messages in conformance
with <span><a href="#RFC9470" class="internal xref">OAuth 2.0 Step Up Authentication Challenge Protocol</a> [<a href="#RFC9470" class="cite xref">RFC9470</a>]</span>.<a href="#section-3.1.3-3.12" class="pilcrow">¶</a>
</dd>
<dd class="break"></dd>
<dt id="section-3.1.3-3.13">dpop_signing_alg_values_supported</dt>
<dd style="margin-left: 1.5em" id="section-3.1.3-3.14">
REQUIRED. A JSON array containing a list of the JWS alg values supported by the client for DPoP proof JWTs.<a href="#section-3.1.3-3.14" class="pilcrow">¶</a>
</dd>
<dd class="break"></dd>
<dt id="section-3.1.3-3.15">jwks_uri or jwks</dt>
<dd style="margin-left: 1.5em" id="section-3.1.3-3.16">client's public key in a JWK Set [RFC7517], or
if jwks_uri is used it MUST be reachable by the Authorization Server and
point to the client's public key set. If the PKI/tls_client_auth method is used, the public key must be issued
by a trusted Certificate Authority.
If either the self-signed mTLS method or private_key_jwt method for client authentication is used, the jwks MUST include a certificate.<a href="#section-3.1.3-3.16" class="pilcrow">¶</a>
</dd>
<dd class="break"></dd>
</dl>
<p id="section-3.1.3-4">
A client using the tls_client_auth authentication method MUST use exactly one of the below metadata parameters to indicate the certificate
subject value that the authorization server is to expect when authenticating the respective client:<a href="#section-3.1.3-4" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-3.1.3-5">
<dt id="section-3.1.3-5.1">tls_client_auth_subject_dn</dt>
<dd style="margin-left: 1.5em" id="section-3.1.3-5.2">String value specifying the expected subject DN of the client certificate.<a href="#section-3.1.3-5.2" class="pilcrow">¶</a>
</dd>
<dd class="break"></dd>
<dt id="section-3.1.3-5.3">tls_client_auth_san_dns</dt>
<dd style="margin-left: 1.5em" id="section-3.1.3-5.4">String value specifying the expected dNSName SAN entry in the client certificate.<a href="#section-3.1.3-5.4" class="pilcrow">¶</a>
</dd>
<dd class="break"></dd>
<dt id="section-3.1.3-5.5">tls_client_auth_san_uri</dt>
<dd style="margin-left: 1.5em" id="section-3.1.3-5.6">String value specifying the expected uniformResourceIdentifier SAN entry in the client certificate.<a href="#section-3.1.3-5.6" class="pilcrow">¶</a>
</dd>
<dd class="break"></dd>
<dt id="section-3.1.3-5.7">tls_client_auth_san_ip</dt>
<dd style="margin-left: 1.5em" id="section-3.1.3-5.8">String value specifying the expected iPAddress SAN entry in the client certificate.<a href="#section-3.1.3-5.8" class="pilcrow">¶</a>
</dd>
<dd class="break"></dd>
<dt id="section-3.1.3-5.9">tls_client_auth_san_email</dt>
<dd style="margin-left: 1.5em" id="section-3.1.3-5.10">String value specifying the expected rfc822Name SAN entry in the client certificate.<a href="#section-3.1.3-5.10" class="pilcrow">¶</a>
</dd>
<dd class="break"></dd>
</dl>
</section>
</div>
<div id="ClientApproval">
<section id="section-3.1.4">
<h4 id="name-client-approval">
<a href="#section-3.1.4" class="section-number selfRef">3.1.4. </a><a href="#name-client-approval" class="section-name selfRef">Client Approval</a>
</h4>
<p id="section-3.1.4-1">When prompting the end user with an interactive approval page,
the authorization server MUST indicate to the user:<a href="#section-3.1.4-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3.1.4-2.1">
<p id="section-3.1.4-2.1.1">Whether the client was dynamically registered, or else
statically registered by a trusted administrator, or a public client.<a href="#section-3.1.4-2.1.1" class="pilcrow">¶</a></p>
</li>
<li class="normal" id="section-3.1.4-2.2">
<p id="section-3.1.4-2.2.1">Whether the client is associated with a software statement,
and in which case provide information about the trusted issuer
of the software statement.<a href="#section-3.1.4-2.2.1" class="pilcrow">¶</a></p>
</li>
<li class="normal" id="section-3.1.4-2.3">
<p id="section-3.1.4-2.3.1">What kind of access the client is requesting, including
scope, protected resources (if applicable beyond scopes),
and access duration.<a href="#section-3.1.4-2.3.1" class="pilcrow">¶</a></p>
</li>
</ul>
<p id="section-3.1.4-3">For example, for
public clients, a message indicating a new App installation has been
registered as a client can help users determine if this is the expected
behavior. This signal helps users protect themselves from potentially
rogue clients.<a href="#section-3.1.4-3" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-3.1.5">
<h4 id="name-sender-constrained-tokens-2">
<a href="#section-3.1.5" class="section-number selfRef">3.1.5. </a><a href="#name-sender-constrained-tokens-2" class="section-name selfRef">Sender-constrained Tokens</a>
</h4>
<p id="section-3.1.5-1"> The authorization server MUST support and verify sender-constrained tokens.<a href="#section-3.1.5-1" class="pilcrow">¶</a></p>
<p id="section-3.1.5-2">The Authorization Server MUST NOT issue the client an access token if the client included the
<code>tls_client_certificate_bound_access_tokens</code>
parameter in its registration metadata and makes a request to the token endpoint over connection not secured by TLS.<a href="#section-3.1.5-2" class="pilcrow">¶</a></p>
</section>
<div id="Discovery">
<section id="section-3.1.6">
<h4 id="name-discovery">
<a href="#section-3.1.6" class="section-number selfRef">3.1.6. </a><a href="#name-discovery" class="section-name selfRef">Discovery</a>
</h4>
<p id="section-3.1.6-1">
The authorization server MUST provide an
<span><a href="#OpenID.Discovery" class="internal xref">OpenID Connect service discovery</a> [<a href="#OpenID.Discovery" class="cite xref">OpenID.Discovery</a>]</span>
endpoint listing the components relevant to the OAuth 2.0 protocol:<a href="#section-3.1.6-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-3.1.6-2">
<dt id="section-3.1.6-2.1">issuer</dt>
<dd style="margin-left: 1.5em" id="section-3.1.6-2.2"> REQUIRED. The fully qualified issuer URL of the
server<a href="#section-3.1.6-2.2" class="pilcrow">¶</a>
</dd>
<dd class="break"></dd>
<dt id="section-3.1.6-2.3">authorization_endpoint</dt>
<dd style="margin-left: 1.5em" id="section-3.1.6-2.4">
REQUIRED. The fully qualified URL of
the server's authorization endpoint
defined by
<span><a href="#RFC6749" class="internal xref">OAuth 2.0</a> [<a href="#RFC6749" class="cite xref">RFC6749</a>]</span><a href="#section-3.1.6-2.4" class="pilcrow">¶</a>
</dd>
<dd class="break"></dd>
<dt id="section-3.1.6-2.5">token_endpoint</dt>
<dd style="margin-left: 1.5em" id="section-3.1.6-2.6">
REQUIRED. The fully qualified URL of the
server's token endpoint defined by
<span><a href="#RFC6749" class="internal xref">OAuth
2.0</a> [<a href="#RFC6749" class="cite xref">RFC6749</a>]</span><a href="#section-3.1.6-2.6" class="pilcrow">¶</a>
</dd>
<dd class="break"></dd>
<dt id="section-3.1.6-2.7">token_endpoint_auth_method</dt>
<dd style="margin-left: 1.5em" id="section-3.1.6-2.8">
REQUIRED. String of values corresponding to permitted methods for client authentication to the authorization server
as defined in <span><a href="#RFC7591" class="internal xref">OAuth 2.0 Dynamic Client Registration Protocol</a> [<a href="#RFC7591" class="cite xref">RFC7591</a>]</span>.
Within this profile, the server MUST provide one or more of the following values: "private_key_jwt", "tls_client_auth",
and "self_signed_tls_auth".<a href="#section-3.1.6-2.8" class="pilcrow">¶</a>
</dd>
<dd class="break"></dd>
<dt id="section-3.1.6-2.9">introspection_endpoint</dt>
<dd style="margin-left: 1.5em" id="section-3.1.6-2.10">
OPTIONAL. The fully qualified URL of
the server's introspection endpoint
defined by
<span><a href="#RFC7662" class="internal xref">OAuth Token Introspection</a> [<a href="#RFC7662" class="cite xref">RFC7662</a>]</span><a href="#section-3.1.6-2.10" class="pilcrow">¶</a>
</dd>
<dd class="break"></dd>
<dt id="section-3.1.6-2.11">revocation_endpoint</dt>
<dd style="margin-left: 1.5em" id="section-3.1.6-2.12">
OPTIONAL. The fully qualified URL of the
server's revocation endpoint
defined by
<span><a href="#RFC7009" class="internal xref">OAuth 2.0 Token Revocation</a> [<a href="#RFC7009" class="cite xref">RFC7009</a>]</span><a href="#section-3.1.6-2.12" class="pilcrow">¶</a>
</dd>
<dd class="break"></dd>
<dt id="section-3.1.6-2.13">mtls_endpoint_aliases</dt>
<dd style="margin-left: 1.5em" id="section-3.1.6-2.14">
OPTIONAL. A JSON object containing alternative
authorization server endpoints that, when present, an OAuth client intending to perform
mutual TLS uses in preference to the conventional endpoints. Use of this parameter enables isolation
of mTLS behavior to only clients intending to use mTLS for authentication or sender-constraining tokens.
Usage of the parameter is specified in
<span><a href="#RFC8705" class="internal xref">OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens</a> [<a href="#RFC8705" class="cite xref">RFC8705</a>]</span><a href="#section-3.1.6-2.14" class="pilcrow">¶</a>
</dd>
<dd class="break"></dd>
<dt id="section-3.1.6-2.15">jwks_uri</dt>
<dd style="margin-left: 1.5em" id="section-3.1.6-2.16">
REQUIRED. The fully qualified URI of the server's
JWK as defined in
<span><a href="#RFC8414" class="internal xref">OAuth 2.0 Authorization Server Metadata</a> [<a href="#RFC8414" class="cite xref">RFC8414</a>]</span>.
If the self_signed_tls_auth method is used, a jwks_uri MUST be registered and MUST include a certificate.<a href="#section-3.1.6-2.16" class="pilcrow">¶</a>
</dd>
<dd class="break"></dd>
</dl>
<p id="section-3.1.6-3">If a client uses <span><a href="#RFC8705" class="internal xref">OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens</a> [<a href="#RFC8705" class="cite xref">RFC8705</a>]</span>S for
client authentication, exactly one authentication method metadata value MUST be included.<a href="#section-3.1.6-3" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-3.1.6-4">
<dt id="section-3.1.6-4.1">tls_client_auth</dt>
<dd style="margin-left: 1.5em" id="section-3.1.6-4.2">Indicates that client authentication to the authorization server will occur with mutual TLS
utilizing the PKI method of associating a certificate to a client.<a href="#section-3.1.6-4.2" class="pilcrow">¶</a>
</dd>
<dd class="break"></dd>
<dt id="section-3.1.6-4.3">self_signed_tls_client_auth</dt>
<dd style="margin-left: 1.5em" id="section-3.1.6-4.4">Indicates that client authentication to the authorization server will occur using mutual TLS
with the client utilizing a self-signed certificate.<a href="#section-3.1.6-4.4" class="pilcrow">¶</a>
</dd>
<dd class="break"></dd>
</dl>
<p id="section-3.1.6-5">If the authorization server is also an OpenID Connect Provider,
it MUST provide a discovery endpoint meeting the requirements
listed
in Section 3.6 of <span><a href="#OpenID.Core" class="internal xref">OpenID Connect Core 1.0</a> [<a href="#OpenID.Core" class="cite xref">OpenID.Core</a>]</span>.<a href="#section-3.1.6-5" class="pilcrow">¶</a></p>
<p id="section-3.1.6-6">The following example shows a JSON document found at the
discovery endpoint for an authorization server:<a href="#section-3.1.6-6" class="pilcrow">¶</a></p>
<div class="alignLeft art-text artwork" id="section-3.1.6-7">
<pre>{
"request_parameter_supported": true,
"registration_endpoint": "https://idp-p.example.com/register",
"userinfo_signing_alg_values_supported": [
"HS256", "HS384", "HS512", "RS256", "RS384", "RS512"
],
"token_endpoint": "https://idp-p.example.com/token",
"request_uri_parameter_supported": false,
"request_object_encryption_enc_values_supported": [
"A192CBC-HS384", "A192GCM", "A256CBC+HS512",
"A128CBC+HS256", "A256CBC-HS512",
"A128CBC-HS256", "A128GCM", "A256GCM"
],
"token_endpoint_auth_methods_supported": [
"private_key_jwt",
],
"jwks_uri": "https://idp-p.example.com/jwk",
"authorization_endpoint": "https://idp-p.example.com/authorize",
"require_request_uri_registration": false,
"introspection_endpoint": "https://idp-p.example.com/introspect",
"request_object_encryption_alg_values_supported": [
"RSA-OAEP", ?RSA1_5", "RSA-OAEP-256"
],
"service_documentation": "https://idp-p.example.com/about",
"response_types_supported": [
"code", "token"
],
"token_endpoint_auth_signing_alg_values_supported": [
"HS256", "HS384", "HS512", "RS256", "RS384", "RS512"
],
"revocation_endpoint": "https://idp-p.example.com/revoke",
"request_object_signing_alg_values_supported": [
"HS256", "HS384", "HS512", "RS256", "RS384", "RS512"
],
"grant_types_supported": [
"authorization_code",
"client_credentials"
],
"scopes_supported": [
"profile", "openid", "email", "address", "phone", "offline_access"
],
"op_tos_uri": "https://idp-p.example.com/about",
"issuer": "https://idp-p.example.com/",
"op_policy_uri": "https://idp-p.example.com/about"
"tls_client_certificate_bound_access_tokens": "true"
"dpop_signing_alg_values_supported": ["PS256", "ES256"]
}
</pre><a href="#section-3.1.6-7" class="pilcrow">¶</a>
</div>
<p id="section-3.1.6-8">It is RECOMMENDED that authorization servers provide cache information through HTTP headers and make the cache valid for at
least one week. This allows clients and protected resources to cache the discovery information.<a href="#section-3.1.6-8" class="pilcrow">¶</a></p>
<p id="section-3.1.6-9"> Authorization servers MUST support the RS256 signature method (the Rivest, Shamir, and Adleman (RSA) signature algorithm
with a 256-bit hash) and MAY use other asymmetric signature methods listed in the JSON Web Algorithms (JWA [RFC7518]) ) specification.<a href="#section-3.1.6-9" class="pilcrow">¶</a></p>
<p id="section-3.1.6-10">The authorization server MUST provide its public key in JWK Set format. The
key
MUST contain the following fields:<a href="#section-3.1.6-10" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-3.1.6-11">
<dt id="section-3.1.6-11.1">kid</dt>
<dd style="margin-left: 1.5em" id="section-3.1.6-11.2">The key ID of the key pair used to sign this
token<a href="#section-3.1.6-11.2" class="pilcrow">¶</a>
</dd>
<dd class="break"></dd>
<dt id="section-3.1.6-11.3">kty</dt>
<dd style="margin-left: 1.5em" id="section-3.1.6-11.4">The key type<a href="#section-3.1.6-11.4" class="pilcrow">¶</a>
</dd>
<dd class="break"></dd>
<dt id="section-3.1.6-11.5">alg</dt>
<dd style="margin-left: 1.5em" id="section-3.1.6-11.6">The default algorithm used for this key<a href="#section-3.1.6-11.6" class="pilcrow">¶</a>
</dd>
<dd class="break"></dd>
</dl>
<p id="section-3.1.6-12">The following is an example of a 2048-bit RSA public key:<a href="#section-3.1.6-12" class="pilcrow">¶</a></p>
<div class="alignLeft art-text artwork" id="section-3.1.6-13">
<pre>{
NOTE: '\' line wrapping per RFC 8792
"keys": [
{
"alg": "RS256",
"e": "AQAB",
"n": "o80vbR0ZfMhjZWfqwPUGNkcIeUcweFyzB2S2T-hje83IOVct8gVg9FxvHP\
K1ReEW3-p7-A8GNcLAuFP_8jPhiL6LyJC3F10aV9KPQFF-w6Eq6VtpEgYSfzvFegNiPt\
pMWd7C43EDwjQ-GrXMVCLrBYxZC-P1ShyxVBOzeR_5MTC0JGiDTecr_2YT6o_3aE2SIJ\
u4iNPgGh9MnyxdBo0Uf0TmrqEIabquXA1-V8iUihwfI8qjf3EujkYi7gXXelIo4_gipQ\
YNjr4DBNlE0__RI0kDU-27mb6esswnP2WgHZQPsk779fTcNDBIcYgyLujlcUATEqfCaP\
DNp00J6AbY6w",
"kty": "RSA",
"kid": "rsa1"
}
]
}
</pre><a href="#section-3.1.6-13" class="pilcrow">¶</a>
</div>
</section>
</div>
<section id="section-3.1.7">
<h4 id="name-revocation">
<a href="#section-3.1.7" class="section-number selfRef">3.1.7. </a><a href="#name-revocation" class="section-name selfRef">Revocation</a>
</h4>
<p id="section-3.1.7-1">Token revocation allows a client to signal to an authorization
server that a given token will no longer be used.<a href="#section-3.1.7-1" class="pilcrow">¶</a></p>
<p id="section-3.1.7-2">Authorization servers MUST provide a revocation endpoint URL as
specified in <span><a href="#RFC7009" class="internal xref">OAuth 2.0 Token Revocation</a> [<a href="#RFC7009" class="cite xref">RFC7009</a>]</span>
for end users to view a list of clients that have been granted access to resources on the
user's behalf and for end users to revoke this access.<a href="#section-3.1.7-2" class="pilcrow">¶</a></p>
<p id="section-3.1.7-3">Authorization servers MUST revoke a token if the client
requesting the revocation is the client to which the token was
issued, the client has permission to revoke tokens, and the token
is able to be revoked.<a href="#section-3.1.7-3" class="pilcrow">¶</a></p>
<p id="section-3.1.7-4">Authorizatin servers MUST NOT allow a client to use a token
after it is revoked.<a href="#section-3.1.7-4" class="pilcrow">¶</a></p>
</section>
<section id="section-3.1.8">
<h4 id="name-pkce">
<a href="#section-3.1.8" class="section-number selfRef">3.1.8. </a><a href="#name-pkce" class="section-name selfRef">PKCE</a>
</h4>
<p id="section-3.1.8-1">Authorization servers MUST require use of PKCE
(<span><a href="#RFC7636" class="internal xref">Proof Key for Code Exchange by OAuth Public Clients</a> [<a href="#RFC7636" class="cite xref">RFC7636</a>]</span>) by all clients
and reject requests to the authorization endpoint from clients that do not contain a code challenge.<a href="#section-3.1.8-1" class="pilcrow">¶</a></p>
<p id="section-3.1.8-2">Authorization servers MUST support the S256 code challenge method. Authorization servers MUST NOT allow a
client to use the plain code challenge method.<a href="#section-3.1.8-2" class="pilcrow">¶</a></p>
<p id="section-3.1.8-3">The PKCE code_verifier value MUST contain at least 128 bits of entropy.<a href="#section-3.1.8-3" class="pilcrow">¶</a></p>
<p id="section-3.1.8-4">Authorization servers MUST confirm thumbprints of client keys.<a href="#section-3.1.8-4" class="pilcrow">¶</a></p>
</section>
<section id="section-3.1.9">
<h4 id="name-redirect-uris">
<a href="#section-3.1.9" class="section-number selfRef">3.1.9. </a><a href="#name-redirect-uris" class="section-name selfRef">Redirect URIs</a>
</h4>
<p id="section-3.1.9-1">The authorization server MUST validate all redirect URIs for authorization code grant types.<a href="#section-3.1.9-1" class="pilcrow">¶</a></p>
<p id="section-3.1.9-2"> To prevent open redirection and other injection attacks, the authorization server MUST match the entire redirect
URI using an exact string match against registered values and MUST reject requests with an invalid or missing redirect URI.<a href="#section-3.1.9-2" class="pilcrow">¶</a></p>
</section>
<section id="section-3.1.10">
<h4 id="name-refresh-tokens">
<a href="#section-3.1.10" class="section-number selfRef">3.1.10. </a><a href="#name-refresh-tokens" class="section-name selfRef">Refresh Tokens</a>
</h4>
<p id="section-3.1.10-1">Authorization servers MAY issue refresh tokens to clients.<a href="#section-3.1.10-1" class="pilcrow">¶</a></p>
</section>
</section>
<section id="section-3.2">
<h3 id="name-response-to-authorization-r">
<a href="#section-3.2" class="section-number selfRef">3.2. </a><a href="#name-response-to-authorization-r" class="section-name selfRef">Response to Authorization Requests</a>
</h3>
<p id="section-3.2-1"> Authorization servers respond to an Authorization Request from a client with an Authorization Response.
The following fields MUST be included in the response:<a href="#section-3.2-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-3.2-2">
<dt id="section-3.2-2.1">state</dt>
<dd style="margin-left: 1.5em" id="section-3.2-2.2"> REQUIRED. The value of the state parameter passed in in the
authentication request. This value MUST match exactly.<a href="#section-3.2-2.2" class="pilcrow">¶</a>
</dd>
<dd class="break"></dd>
<dt id="section-3.2-2.3">code</dt>
<dd style="margin-left: 1.5em" id="section-3.2-2.4"> REQUIRED. The authorization code, a random string issued by
the IdP to be used in the request to the token endpoint.<a href="#section-3.2-2.4" class="pilcrow">¶</a>
</dd>
<dd class="break"></dd>
</dl>
<p id="section-3.2-3">
PKCE parameters MUST be associated with the authorization code as per Section 4.4 of
<span><a href="#RFC7636" class="internal xref">Proof Key for Code Exchange by OAuth Public Clients (PKCE)</a> [<a href="#RFC7636" class="cite xref">RFC7636</a>]</span>.<a href="#section-3.2-3" class="pilcrow">¶</a></p>
<p id="section-3.2-4"> The following is an example response:<a href="#section-3.2-4" class="pilcrow">¶</a></p>
<div class="alignLeft art-text artwork" id="section-3.2-5">
<pre>
https://https://client.example.org/cb?
state=2ca3359dfbfd0
&code=gOIFJ1hV6Rb1sxUdFhZGACWwR1sMhYbJJcQbVJN0wHA
</pre><a href="#section-3.2-5" class="pilcrow">¶</a>
</div>
</section>
<div id="JWTokens">
<section id="section-3.3">
<h3 id="name-json-web-tokens-jwt">
<a href="#section-3.3" class="section-number selfRef">3.3. </a><a href="#name-json-web-tokens-jwt" class="section-name selfRef">JSON Web Tokens (JWT)</a>
</h3>
<p id="section-3.3-1">Authorization servers MUST issue
cryptographically signed sender-constrained tokens in the JSON Web Token (JWT)
format as defined in <span><a href="#RFC9068" class="internal xref">JSON Web Token (JWT) Profile for OAuth
2.0 Access Tokens</a> [<a href="#RFC9068" class="cite xref">RFC9068</a>]</span>.
The information carried in the JWT is intended to allow a
protected
resource to quickly test the integrity of the token
without
additional network calls, and to allow the protected
resource to
determine which authorization server issued the token.
The protected resource MAY use the authorization server token introspection service
to retrieve additional security information about the token.<a href="#section-3.3-1" class="pilcrow">¶</a></p>
<p id="section-3.3-2">The server MUST issue tokens as JWTs with, at minimum, the
following claims:<a href="#section-3.3-2" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-3.3-3">
<dt id="section-3.3-3.1">iss</dt>
<dd style="margin-left: 1.5em" id="section-3.3-3.2">The issuer URL of the server that issued the
token<a href="#section-3.3-3.2" class="pilcrow">¶</a>
</dd>
<dd class="break"></dd>
<dt id="section-3.3-3.3">client_id</dt>
<dd style="margin-left: 1.5em" id="section-3.3-3.4">The client id of the client to whom this token
was
issued<a href="#section-3.3-3.4" class="pilcrow">¶</a>
</dd>
<dd class="break"></dd>
<dt id="section-3.3-3.5">exp</dt>
<dd style="margin-left: 1.5em" id="section-3.3-3.6">The expiration time (integer number of seconds
since from 1970-01-01T00:00:00Z UTC), after which the token MUST
be considered invalid<a href="#section-3.3-3.6" class="pilcrow">¶</a>
</dd>
<dd class="break"></dd>
<dt id="section-3.3-3.7">jti</dt>
<dd style="margin-left: 1.5em" id="section-3.3-3.8">A unique JWT Token ID value with at least 128
bits
of entropy. This value MUST NOT be re-used in another
token.
Clients MUST check for reuse of jti values and reject all
tokens
issued with duplicate jti values.<a href="#section-3.3-3.8" class="pilcrow">¶</a>
</dd>
<dd class="break"></dd>
<dt id="section-3.3-3.9">sub</dt>
<dd style="margin-left: 1.5em" id="section-3.3-3.10">The identifier of the end-user that authorized
this
client, or the client id of a client acting on its own
behalf
(such as a bulk transfer). Since this information could
potentially leak private user information, it should be used
only when needed. End-user identifiers SHOULD be pairwise
anonymous identifiers unless the audience requires otherwise.<a href="#section-3.3-3.10" class="pilcrow">¶</a>
</dd>
<dd class="break"></dd>
<dt id="section-3.3-3.11">aud</dt>
<dd style="margin-left: 1.5em" id="section-3.3-3.12">The audience of the token, an array containing
the
identifier(s) of protected resource(s) for which the token
is
valid, if this information is known. The aud claim may
contain
multiple values if the token is valid for multiple
protected
resources. Note that at runtime, the authorization
server may not
know the identifiers of all possible protected
resources at which
a token may be used.<a href="#section-3.3-3.12" class="pilcrow">¶</a>
</dd>
<dd class="break"></dd>
<dt id="section-3.3-3.13">scope</dt>
<dd style="margin-left: 1.5em" id="section-3.3-3.14">The value of the scope claim is a JSON string containing a
space-separated list of scopes associated with the token, in the format
described in Section 3.3 of <span><a href="#RFC6749" class="internal xref">The OAuth 2.0 Authorization
Framework</a> [<a href="#RFC6749" class="cite xref">RFC6749</a>]</span>.<a href="#section-3.3-3.14" class="pilcrow">¶</a>
</dd>
<dd class="break"></dd>
<dt id="section-3.3-3.15">iat</dt>
<dd style="margin-left: 1.5em" id="section-3.3-3.16">The "iat" (issued at) claim identifies the time at which the JWT
was issued. This claim can be used to determine the age of the JWT. Its value MUST
be a number containing a NumericDate value.<a href="#section-3.3-3.16" class="pilcrow">¶</a>
</dd>
<dd class="break"></dd>
<dt id="section-3.3-3.17">cnf</dt>
<dd style="margin-left: 1.5em" id="section-3.3-3.18">The confirmation claim, as defined in <span><a href="#RFC7800" class="internal xref">Proof-of-Possession Key Semantics
for JSON Web Tokens (JWTs)</a> [<a href="#RFC7800" class="cite xref">RFC7800</a>]</span> and <span><a href="#RFC8705" class="internal xref">OAuth 2.0 Mutual-TLS
Client Authentication and Certificate-Bound Access Tokens</a> [<a href="#RFC8705" class="cite xref">RFC8705</a>]</span> is used in a JWT to contain
members used to identify the proof-of-possession key.<a href="#section-3.3-3.18" class="pilcrow">¶</a>
</dd>
<dd class="break"></dd>
<dt id="section-3.3-3.19"></dt>
<dd style="margin-left: 1.5em" id="section-3.3-3.20">When <span><a href="#RFC8705" class="internal xref">OAuth 2.0 Mutual-TLS
Client Authentication and Certificate-Bound Access Tokens</a> [<a href="#RFC8705" class="cite xref">RFC8705</a>]</span>is used, the confirmation
claim value MUST be computed using the
X.509 Certificate SHA-256 Thumbprint and include confirmation
method value "x5t#256".<a href="#section-3.3-3.20" class="pilcrow">¶</a>
</dd>
<dd class="break"></dd>
<dt id="section-3.3-3.21"></dt>
<dd style="margin-left: 1.5em" id="section-3.3-3.22">When <span><a href="#RFC9449" class="internal xref">OAuth 2.0 Demonstrating Proof of Possession (DPoP)</a> [<a href="#RFC9449" class="cite xref">RFC9449</a>]</span>
is used, the confirmation claim value MUST be computed using the <span><a href="#RFC7638" class="internal xref">JWK SHA-256
Thumbprint</a> [<a href="#RFC7638" class="cite xref">RFC7638</a>]</span> of the DPoP public key and include conformation method value jkt.<a href="#section-3.3-3.22" class="pilcrow">¶</a>
</dd>
<dd class="break"></dd>
</dl>
<p id="section-3.3-4">In order to support backwards compatibility, AS MAY include the azp claim while resource servers
modernize.<a href="#section-3.3-4" class="pilcrow">¶</a></p>
<p id="section-3.3-5">The following sample claim set illustrates the use of the
required claims for an access token as defined in this profile;
additional claims MAY be included in the claim set:<a href="#section-3.3-5" class="pilcrow">¶</a></p>
<div class="alignLeft art-text artwork" id="section-3.3-6">
<pre>{
"exp": 1418702388,
"client_id": "55f9f559-2496-49d4-b6c3-351a586b7484",
"azp": "55f9f559-2496-49d4-b6c3-351a586b7484",
"iss": "https://idp-p.example.com/",
"sub" : "93ff28e3-3982-c34b-f2a4-98bb3d42b277",
"jti": "2402f87c-b6ce-45c4-95b0-7a3f2904997f",
"iat": 1418698788,
"scope" : "MyResource1 MyResource2",
"acr": "myACR",
"auth_time": 16463400198,
"cnf": {
"x5t#S256":"A4DtL2JmUMhAsvJj5tKyn64SqzmuXbMrJa0n761y5v0"
}
}
</pre><a href="#section-3.3-6" class="pilcrow">¶</a>
</div>
<p id="section-3.3-7">
The access tokens MUST be signed with
<span><a href="#RFC7515" class="internal xref">JWS</a> [<a href="#RFC7515" class="cite xref">RFC7515</a>]</span>
. If private_key_jwt is used, the authorization server MUST support
the RS256 signature method
for tokens and MAY use other asymmetric
signing methods as defined
in the
<span><a href="#JWS.JWE.Algs" class="internal xref">IANA
JSON Web Signatures and Encryption
Algorithms registry</a> [<a href="#JWS.JWE.Algs" class="cite xref">JWS.JWE.Algs</a>]</span>
. The
JWS header MUST contain the following fields:<a href="#section-3.3-7" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-3.3-8">
<dt id="section-3.3-8.1">kid</dt>
<dd style="margin-left: 1.5em" id="section-3.3-8.2">The key ID of the key pair used to sign this
token<a href="#section-3.3-8.2" class="pilcrow">¶</a>
</dd>
<dd class="break"></dd>
</dl>
<p id="section-3.3-9">This example access token has been signed with the server's
private key using RS256:<a href="#section-3.3-9" class="pilcrow">¶</a></p>
<div class="alignLeft art-text artwork" id="section-3.3-10">
<pre>
NOTE: '\' line wrapping per RFC 8792
eyJhbGciOiJSUzI1NiJ9.ew0KICAgImV4cCI6IDE0MTg3MDIzODgsDQogICAiYXpwIjo\
gIjU1ZjlmNTU5LTI0OTYtNDlkNC1iNmMzLTM1MWE1ODZiNzQ4NCIsDQogICAiaXNzIjo\
gImh0dHBzOi8vaWRwLXAuZXhhbXBsZS5jb20vIiwNCiAgICJqdGkiOiAiMjQwMmY4N2M\
tYjZjZS00NWM0LTk1YjAtN2EzZjI5MDQ5OTdmIiwNCiAgICJpYXQiOiAxNDE4Njk4Nzg\
4LA0KICAgImtpZCI6ICJyc2ExIg0KfQ.iB6Ix8Xeg-L-nMStgE1X75w7zgXabzw7znWU\
ECOsXpHfnYYqb-CET9Ah5IQyXIDZ20qEyN98UydgsTpiO1YJDDcZV4f4DgY0ZdG3yBW3\
XqwUQwbgF7Gwza9Z4AdhjHjzQx-lChXAyfL1xz0SBDkVbJdDjtXbvaSIyfF7ueWF3M1C\
M70-GXuRY4iucKbuytz9e7eW4Egkk4Aagl3iTk9-l5V-tvL6dYu8IlR93GKsaKE8bng0\
EZ04xcnq8s4V5Yykuc_NARBJENiKTJM8w3wh7xWP2gvMp39Y0XnuCOLyIx-J1ttX83xm\
pXDaLyyY-4HT9XHT9V73fKF8rLWJu9grrA
</pre><a href="#section-3.3-10" class="pilcrow">¶</a>
</div>
<p id="section-3.3-11">
Refresh tokens SHOULD be signed with
<span><a href="#RFC7515" class="internal xref">JWS</a> [<a href="#RFC7515" class="cite xref">RFC7515</a>]</span>
using the same private key and contain
the same set of claims as
the
access tokens.<a href="#section-3.3-11" class="pilcrow">¶</a></p>
<p id="section-3.3-12">
The authorization server MAY encrypt access tokens and refresh
tokens using
<span><a href="#RFC7516" class="internal xref">JWE</a> [<a href="#RFC7516" class="cite xref">RFC7516</a>]</span>
. Encrypted access
tokens MUST be encrypted using the public key of
the protected
resource. Encrypted refresh tokens MUST be encrypted
using the
authorization server's public key.<a href="#section-3.3-12" class="pilcrow">¶</a></p>
<p id="section-3.3-13">The client SHOULD use a certificate to sender-constrain tokens that is distinct from the certificate used to connect
to the protected resource.<a href="#section-3.3-13" class="pilcrow">¶</a></p>
</section>
</div>
<div id="TokenLifetimes">
<section id="section-3.4">
<h3 id="name-token-lifetimes">
<a href="#section-3.4" class="section-number selfRef">3.4. </a><a href="#name-token-lifetimes" class="section-name selfRef">Token Lifetimes</a>
</h3>
<p id="section-3.4-1">Access tokens SHOULD have a valid lifetime no greater than one hour, and
refresh tokens (if issued) SHOULD have a valid lifetime no greater
than twenty-four hours. Specific applications MAY issue tokens with different lifetimes.
Any active token MAY be revoked at any time.<a href="#section-3.4-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="Scopes">
<section id="section-3.5">
<h3 id="name-scopes">
<a href="#section-3.5" class="section-number selfRef">3.5. </a><a href="#name-scopes" class="section-name selfRef">Scopes</a>
</h3>
<p id="section-3.5-1">Scopes define individual pieces of authority that can be
requested
by clients, granted by resource owners, and enforced by
protected
resources. Specific scope values will be highly dependent
on the
specific types of resources being protected in a given
interface.
OpenID Connect, for example, defines scope values to
enable access
to
different attributes of user profiles.<a href="#section-3.5-1" class="pilcrow">¶</a></p>
<p id="section-3.5-2">Authorization servers SHOULD define and document default scope
values that will be used if an authorization request does not
specify
a requested set of scopes.<a href="#section-3.5-2" class="pilcrow">¶</a></p>
<p id="section-3.5-3">To facilitate general use across a wide variety of protected
resources, authorization servers SHOULD allow for the use of
arbitrary
scope values at runtime, such as allowing clients or
protected
resources to use arbitrary scope strings upon
registration.
Authorization servers MAY restrict certain scopes from
use by
dynamically registered systems or public clients.<a href="#section-3.5-3" class="pilcrow">¶</a></p>
<p id="section-3.5-4">Refer to <a href="#ClientApproval" class="auto internal xref">Section 3.1.4</a> for further information about
displaying scopes to end users.<a href="#section-3.5-4" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-3.6">
<h3 id="name-connections-between-authori">
<a href="#section-3.6" class="section-number selfRef">3.6. </a><a href="#name-connections-between-authori" class="section-name selfRef">Connections Between Authorization Servers and Protected Resources</a>
</h3>
<section id="section-3.6.1">
<h4 id="name-introspection">
<a href="#section-3.6.1" class="section-number selfRef">3.6.1. </a><a href="#name-introspection" class="section-name selfRef">Introspection</a>
</h4>
<p id="section-3.6.1-1">Token introspection allows a protected resource to query the
authorization server for metadata about a token. Authorization servers MUST NOT allow clients to use token introspection endpoints.<a href="#section-3.6.1-1" class="pilcrow">¶</a></p>
<p id="section-3.6.1-2">The protected
resource makes a request over a mutually authenticated TLS connection like the following to the token
introspection endpoint:<a href="#section-3.6.1-2" class="pilcrow">¶</a></p>
<div class="alignLeft art-text artwork" id="section-3.6.1-3">
<pre>
NOTE: '\' line wrapping per RFC 8792
POST /introspect HTTP/1.1
User-Agent: Faraday v0.9.0
Content-Type: application/x-www-form-urlencoded
Accept-Encoding: gzip;q=1.0,deflate;q=0.6,identity;q=0.3
Accept: */*
Connection: close
Host: as-va.example.com
Content-Length: 1412
client_assertion=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiJ9.eyJpc3MiOiJhMm\
MzNjkxOS0wMWZmLTQ4MTAtYTgyOS00MDBmYWQzNTczNTEiLCJzdWIiOiJhMmMzNjkxOS\
0wMWZmLTQ4MTAtYTgyOS00MDBmYWQzNTczNTEiLCJhdWQiOiJodHRwczovL2FzLXZhLm\
V4YW1wbGUuY29tL3Rva2VuIiwiaWF0IjoxNDE4Njk4ODE0LCJleHAiOjE0MTg2OTg4Nz\
QsImp0aSI6IjE0MTg2OTg4MTQvZmNmNDQ2OGY2MDVjNjE1NjliOWYyNGY5ODJlMTZhZW\
Y2OTU4In0.md7mFdNBaGhiJfE_pFkAAWA5S-JBvDw9Dk7pOOJEWcL08JGgDFoi9UDbg3\
sHeA5DrrCYGC_zw7fCGc9ovpfMB7W6YN53hGU19LtzzFN3tv9FNRq4KIzhK15pns9jck\
Ktui3HZ25L_B-BnxHe7xNo3kA1M-p51uYYIM0hw1SRi2pfwBKG5O8WntybLjuJ0R3X97\
zvqHn2Q7xdVyKlInyNPA8gIZK0HVssXxHOI6yRrAqvdMn_sneDTWPrqVpaR_c7rt8Ddd\
7drf_nTD1QxESVhYqKTax5Qfd-aq8gZz8gJCzS0yyfQh6DmdhmwgrSCCRC6BUQkeFNvj\
MVEYHQ9fr0NA
&client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertio\
n-type%3Ajwt-bearer
&client_id=a2c36919-01ff-4810-a829-400fad357351
&token=eyJhbGciOiJSUzI1NiJ9.eyJleHAiOjE0MTg3MDI0MTQsImF1ZCI6WyJlNzFm\
YjcyYS05NzRmLTQwMDEtYmNiNy1lNjdjMmJjMDAzN2YiXSwiaXNzIjoiaHR0cHM6XC9c\
L2FzLXZhLmV4YW1wbGUuY29tXC8iLCJqdGkiOiIyMWIxNTk2ZC04NWQzLTQzN2MtYWQ4\
My1iM2YyY2UyNDcyNDQiLCJpYXQiOjE0MTg2OTg4MTR9.FXDtEzDLbTHzFNroW7w27RL\
k5m0wprFfFH7h4bdFw5fR3pwiqejKmdfAbJvN3_yfAokBv06we5RARJUbdjmFFfRRW23\
cMbpGQCIk7Nq4L012X_1J4IewOQXXMLTyWQQ_BcBMjcW3MtPrY1AoOcfBOJPx1k2jwRk\
YtyVTLWlff6S5gK-ciYf3b0bAdjoQEHd_IvssIPH3xuBJkmtkrTlfWR0Q0pdpeyVePkM\
SI28XZvDaGnxA4j7QI5loZYeyzGR9h70xQLVzqwwl1P0-F_0JaDFMJFO1yl4IexfpoZZ\
sB3HhF2vFdL6D_lLeHRy-H2g2OzF59eMIsM_Ccs4G47862w
</pre><a href="#section-3.6.1-3" class="pilcrow">¶</a>
</div>
<p id="section-3.6.1-4">
The client assertion parameter is structured as described in
<a href="#RequestsToTokenEndpoint" class="auto internal xref">Section 2.6.2</a>.<a href="#section-3.6.1-4" class="pilcrow">¶</a></p>
<p id="section-3.6.1-5">Authorization servers respond to an introspection request with a JSON
object containing the following fields as
defined in <span><a href="#RFC7662" class="internal xref">OAuth 2.0 Token Introspection</a> [<a href="#RFC7662" class="cite xref">RFC7662</a>]</span>.<a href="#section-3.6.1-5" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-3.6.1-6">
<dt id="section-3.6.1-6.1">active</dt>
<dd style="margin-left: 1.5em" id="section-3.6.1-6.2">Boolean value indicating whether or not
this token
is currently active at this authorization server.
Tokens that
have been revoked, have expired, or were not issued
by this
authorization server are considered non-active.<a href="#section-3.6.1-6.2" class="pilcrow">¶</a>
</dd>
<dd class="break"></dd>
<dt id="section-3.6.1-6.3">scope</dt>
<dd style="margin-left: 1.5em" id="section-3.6.1-6.4">Space-separated list of OAuth 2.0 scope
values represented as a single string.<a href="#section-3.6.1-6.4" class="pilcrow">¶</a>
</dd>
<dd class="break"></dd>
<dt id="section-3.6.1-6.5">exp</dt>
<dd style="margin-left: 1.5em" id="section-3.6.1-6.6">Timestamp of when this token expires (integer
number of seconds since from 1970-01-01T00:00:00Z UTC)<a href="#section-3.6.1-6.6" class="pilcrow">¶</a>
</dd>
<dd class="break"></dd>
<dt id="section-3.6.1-6.7">sub</dt>
<dd style="margin-left: 1.5em" id="section-3.6.1-6.8">An opaque string that uniquely identifies the
user
who authorized this token at this authorization server (if
applicable). This string MAY be diversified per client.<a href="#section-3.6.1-6.8" class="pilcrow">¶</a>
</dd>
<dd class="break"></dd>
<dt id="section-3.6.1-6.9">client_id</dt>
<dd style="margin-left: 1.5em" id="section-3.6.1-6.10">An opaque string that uniquely
identifies the OAuth
2.0 client that requested this token<a href="#section-3.6.1-6.10" class="pilcrow">¶</a>
</dd>
<dd class="break"></dd>
</dl>
<p id="section-3.6.1-7">The following example is a response from the introspection
endpoint:<a href="#section-3.6.1-7" class="pilcrow">¶</a></p>
<div class="alignLeft art-text artwork" id="section-3.6.1-8">
<pre>HTTP/1.1 200 OK
Date: Tue, 16 Dec 2014 03:00:14 GMT
Access-Control-Allow-Origin: *
Content-Type: application/json;charset=ISO-8859-1
Content-Language: en-US
Content-Length: 266
Connection: close
{
"active": true,
"scope": "file search visa",
"exp": 1418702414,
"sub": "{sub\u003d6WZQPpnQxV, iss\u003dhttps://idp-p.example.com/}",
"client_id": "e71fb72a-974f-4001-bcb7-e67c2bc0037f",
"token_type": "Bearer"
}
</pre><a href="#section-3.6.1-8" class="pilcrow">¶</a>
</div>
<p id="section-3.6.1-9">
Authorization servers MUST require authentication of resource servers
for the introspection endpoint using either private_key_jwt or Mutual-TLS
methods as described for clients in
<a href="#RequestsToTokenEndpoint" class="auto internal xref">Section 2.6.2</a>. Authorization servers MUST NOT allow clients to
use token introspection endpoints.<a href="#section-3.6.1-9" class="pilcrow">¶</a></p>
</section>
</section>
</section>
</div>
<section id="section-4">
<h2 id="name-protected-resource-profile">
<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-protected-resource-profile" class="section-name selfRef">Protected Resource Profile</a>
</h2>
<section id="section-4.1">
<h3 id="name-connections-with-clients-2">
<a href="#section-4.1" class="section-number selfRef">4.1. </a><a href="#name-connections-with-clients-2" class="section-name selfRef">Connections with Clients</a>
</h3>
<p id="section-4.1-1">Protected resources MUST interpret access tokens using either JWT, token introspection, or a combination of the two<a href="#section-4.1-1" class="pilcrow">¶</a></p>
<p id="section-4.1-2">Protected resources MUST check the
<code>aud</code>
(audience) claim in tokens to ensure that it
includes the protected resource's identifier.<a href="#section-4.1-2" class="pilcrow">¶</a></p>
<p id="section-4.1-3">
Protected resources MUST accept tokens passed in the
authorization header as described in
<span>[<a href="#RFC6750" class="cite xref">RFC6750</a>]</span>. A
protected resource MUST NOT accept tokens passed in the
form
parameter or query parameter methods.<a href="#section-4.1-3" class="pilcrow">¶</a></p>
<p id="section-4.1-4">Protected resources MUST define and document which scopes are
required for access to the resource and any authentication strength or recency requirements for each scope.<a href="#section-4.1-4" class="pilcrow">¶</a></p>
<p id="section-4.1-5"> If a client <span><a href="#RFC8705" class="internal xref">mTLS</a> [<a href="#RFC8705" class="cite xref">RFC8705</a>]</span> to sender-constrain tokens, the protected resource
MUST verify that the certificate matches the certificate associated with the
access token. If they do not match, the resource access attempt MUST be denied.<a href="#section-4.1-5" class="pilcrow">¶</a></p>
<p id="section-4.1-6">Protected resources MAY use authentication context or step up authentication to implement access controls.<a href="#section-4.1-6" class="pilcrow">¶</a></p>
<p id="section-4.1-7">If the authentication event associated with the access token does not satisfy the requirements of the resource server for the given request,
the protected resource MUST return a 401 Unauthorized status code along with a WWW-Authenticate header as defined in <span><a href="#RFC9470" class="internal xref">OAuth
2.0 Step Up Authentication Challenge Protocol</a> [<a href="#RFC9470" class="cite xref">RFC9470</a>]</span>. This header MUST include the insufficient_user_authentication error code to indicate that the
presented access token is inadequate.<a href="#section-4.1-7" class="pilcrow">¶</a></p>
<p id="section-4.1-8">Additionally, the response MUST include the acr_values and/or max_age auth-params to communicate the necessary authentication context
class reference values and the allowable elapsed time since the last active authentication event, respectively. The acr_values parameter
should list the required authentication context class reference values in order of preference, while the max_age parameter should indicate
the maximum permissible time in seconds since the last user authentication.<a href="#section-4.1-8" class="pilcrow">¶</a></p>
<p id="section-4.1-9">The mechanisms by which the protected resource determines whether the authentication requirements are met are outside the scope of this profile.<a href="#section-4.1-9" class="pilcrow">¶</a></p>
<p id="section-4.1-10">Furthermore, protected resources MAY include both acr_values and max_age if both are relevant.<a href="#section-4.1-10" class="pilcrow">¶</a></p>
<p id="section-4.1-11">Protected resources MAY include the scope parameter if additional scopes are required to access the resource, as per Section 3.1 of
<span><a href="#RFC6750" class="internal xref">The OAuth 2.0 Authorization Framework: Bearer Token Usage</a> [<a href="#RFC6750" class="cite xref">RFC6750</a>]</span>.<a href="#section-4.1-11" class="pilcrow">¶</a></p>
</section>
<div id="ProtectingResources">
<section id="section-4.2">
<h3 id="name-protecting-resources">
<a href="#section-4.2" class="section-number selfRef">4.2. </a><a href="#name-protecting-resources" class="section-name selfRef">Protecting Resources</a>
</h3>
<div id="TrustLevels">
<section id="section-4.2.1">
<h4 id="name-trust-levels-and-scopes">
<a href="#section-4.2.1" class="section-number selfRef">4.2.1. </a><a href="#name-trust-levels-and-scopes" class="section-name selfRef">Trust Levels and Scopes</a>
</h4>
<p id="section-4.2.1-1">Protected Resources grant access to clients if they present a valid sender-constrained
<code>access_token</code> with the appropriate
scopes. Resource servers trust the
authorization server to authenticate the end user and client appropriately
for the importance, risk, and value level of the protected
resource scope.<a href="#section-4.2.1-1" class="pilcrow">¶</a></p>
<p id="section-4.2.1-2">Protected resources MAY use <span><a href="#RFC9470" class="internal xref">OAuth 2.0 Step Up Authentication Challenge Protocol</a> [<a href="#RFC9470" class="cite xref">RFC9470</a>]</span> to implement access controls.<a href="#section-4.2.1-2" class="pilcrow">¶</a></p>
<p id="section-4.2.1-3"> If a protected resources requires a higher end-user authentication trust
level to access certain resources, the protected resource MUST associate those resources with a
unique scope and MUST associate acceptable acr values for each scope as descibed in
<span><a href="#RFC9470" class="internal xref">OAuth 2.0 Step Up Authentication Challenge Protocol</a> [<a href="#RFC9470" class="cite xref">RFC9470</a>]</span>.
Protected Resources may also specify a max_age for each scope.<a href="#section-4.2.1-3" class="pilcrow">¶</a></p>
<p id="section-4.2.1-4">Protected resources MAY include the scope parameter if additional scopes are required to access the resource, as per Section 3.1 of
<span><a href="#RFC6750" class="internal xref">The OAuth 2.0 Authorization Framework: Bearer Token Usage</a> [<a href="#RFC6750" class="cite xref">RFC6750</a>]</span>.<a href="#section-4.2.1-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="TrustExample">
<section id="section-4.2.2">
<h4 id="name-trust-levels-example">
<a href="#section-4.2.2" class="section-number selfRef">4.2.2. </a><a href="#name-trust-levels-example" class="section-name selfRef">Trust Levels Example</a>
</h4>
<p id="section-4.2.2-1">For example, a resource server associates
scopes with data classified as "public" and "sensitive".
Access to data with scope "sensitive" requires the user to perform a two-factor authentication
and limits those access grants to only 15 minutes.
The resource server associates scope "sensitive" with acr="MFA".<a href="#section-4.2.2-1" class="pilcrow">¶</a></p>
<p id="section-4.2.2-2">
For a client to obtain access to both "public" and "sensitive" data,
it makes an authorization request to the authorization server with
<code>scope=public+sensitive</code>, acr_values="MFA", and
max_age=900. The authorization
server authenticates the end-user as required to meet the required trust level
(two-factor authentication or some approved equivalent) and issues an
<code>access_token</code> for the "public" and "sensitive" scopes
with an expiry time of 15 minutes and a <code>refresh_token</code>
for the "public" scope with an expiry time of 24 hrs.<a href="#section-4.2.2-2" class="pilcrow">¶</a></p>
<p id="section-4.2.2-3">
The client can access both
"public" and "sensitive" data for 15mins with the access_token. When the
access_token expires, the client will NOT be able to access "public" or "sensitive"
data any longer as the access_token has expired, and must obtain a
new access_token.<a href="#section-4.2.2-3" class="pilcrow">¶</a></p>
<p id="section-4.2.2-4">
The client makes a
refresh token request (as described in <span><a href="#RFC6749" class="internal xref">OAuth 2.0</a> [<a href="#RFC6749" class="cite xref">RFC6749</a>]</span>
section 6) with the refresh_token,
and the reduced scope of just "public". The token endpoint validates the refresh_token,
and issues a new access_token for just the "public" scope with an expiry time set to 24hrs.
An access grant request for a new access_token with the "sensitive" scope would be
rejected, and require the client to get the end-user to re-authenticate/authorize the
"sensitive" scope request.<a href="#section-4.2.2-4" class="pilcrow">¶</a></p>
<p id="section-4.2.2-5"> In this manner, protected resources and authorization servers work together to meet
risk tolerance levels for sensitive resources and end-user authentication.<a href="#section-4.2.2-5" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<section id="section-4.3">
<h3 id="name-connections-with-authorizat">
<a href="#section-4.3" class="section-number selfRef">4.3. </a><a href="#name-connections-with-authorizat" class="section-name selfRef">Connections with Authorization Servers</a>
</h3>
<p id="section-4.3-1">Protected resources MUST provide a JWKS URI endpoint to distribute public keys to support signing, encryption, and
authentication to authorization server revocation and introspection endpoints. <span><a href="#draft-resource-metadata" class="internal xref">OAuth 2.0 Protected Resource Metadata</a> [<a href="#draft-resource-metadata" class="cite xref">draft-resource-metadata</a>]</span>
defines a metadata format that a client or authorization server can use to obtain the information needed to interact with a protected resource.
This metadata facilitates enhanced interoperability and security, including advertisement and discovery of a protected
resource's public key via its jwks_uri.<a href="#section-4.3-1" class="pilcrow">¶</a></p>
<p id="section-4.3-2">Protected resources calling the
introspection endpoint MUST use
credentials distinct from any other
OAuth client registered at the authorization
server.<a href="#section-4.3-2" class="pilcrow">¶</a></p>
<p id="section-4.3-3">Protected resources MAY cache the response from the
introspection endpoint for a period of time no greater than half
the
lifetime of the token. A protected resource MUST NOT accept a
token
that is not active according to the response from the
introspection
endpoint.<a href="#section-4.3-3" class="pilcrow">¶</a></p>
<p id="section-4.3-4">Protected
resources
MUST ensure that the rights associated with the token are
sufficient
to grant access to the resource. For example, this can be
accomplished
by querying the scopes and acr value associated with the token from
the
authorization server's token introspection endpoint.<a href="#section-4.3-4" class="pilcrow">¶</a></p>
<p id="section-4.3-5">Protected resources MUST limit which authorization servers it
will
accept valid tokens from. A resource server MAY accomplish
this using
a whitelist of trusted servers, a dynamic policy engine,
or other
means.<a href="#section-4.3-5" class="pilcrow">¶</a></p>
</section>
</section>
<section id="section-5">
<h2 id="name-security-considerations">
<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a>
</h2>
<section id="section-5.1">
<h3 id="name-dnssec-considerations">
<a href="#section-5.1" class="section-number selfRef">5.1. </a><a href="#name-dnssec-considerations" class="section-name selfRef">DNSSEC Considerations</a>
</h3>
<p id="section-5.1-1">For a comprehensive protection against network attackers, all endpoints should additionally use <span><a href="#RFC9364" class="internal xref">DNSSEC</a> [<a href="#RFC9364" class="cite xref">RFC9364</a>]</span> to protect
against DNS spoofing attacks that can lead to the issuance of rogue domain-validated TLS certificates.<a href="#section-5.1-1" class="pilcrow">¶</a></p>
</section>
<section id="section-5.2">
<h3 id="name-best-practices">
<a href="#section-5.2" class="section-number selfRef">5.2. </a><a href="#name-best-practices" class="section-name selfRef">Best Practices</a>
</h3>
<p id="section-5.2-1">Authorization server, client, and protected resource implementations SHOULD consider including requirements from
<span><a href="#BCP240" class="internal xref">Best Current Practice for OAuth 2.0 Security</a> [<a href="#BCP240" class="cite xref">BCP240</a>]</span>,
<span><a href="#RFC8725" class="internal xref">JSON Web Token Best Current Practices</a> [<a href="#RFC8725" class="cite xref">RFC8725</a>]</span> and
<span><a href="#RFC9068" class="internal xref">JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens</a> [<a href="#RFC9068" class="cite xref">RFC9068</a>]</span> that are not
explicitly mentioned in this profile.<a href="#section-5.2-1" class="pilcrow">¶</a></p>
</section>
<section id="section-5.3">
<h3 id="name-other-considerations">
<a href="#section-5.3" class="section-number selfRef">5.3. </a><a href="#name-other-considerations" class="section-name selfRef">Other Considerations</a>
</h3>
<p id="section-5.3-1"> Authorization Servers SHOULD take into account device posture when dealing
with native apps if possible. Some examples of device posture include:<a href="#section-5.3-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-5.3-2.1">
<p id="section-5.3-2.1.1">the user's lock screen setting<a href="#section-5.3-2.1.1" class="pilcrow">¶</a></p>
</li>
<li class="normal" id="section-5.3-2.2">
<p id="section-5.3-2.2.1">the app's level of privilege over the device operating system (e.g. if the app has 'root access', the
device operating system may be compromised to gain additional privileges not intended by the vendor)<a href="#section-5.3-2.2.1" class="pilcrow">¶</a></p>
</li>
<li class="normal" id="section-5.3-2.3">
<p id="section-5.3-2.3.1">the availability of a device attestation to validate the app<a href="#section-5.3-2.3.1" class="pilcrow">¶</a></p>
</li>
</ul>
<p id="section-5.3-3">
Specific policies or capabilities are outside the scope of this specification.<a href="#section-5.3-3" class="pilcrow">¶</a></p>
<p id="section-5.3-4">
This profile does not protect against the attacks described in
<span><a href="#pkce-vs-nonce" class="internal xref">The Stronger Attacker Model</a> [<a href="#pkce-vs-nonce" class="cite xref">pkce-vs-nonce</a>]</span>, in which an attacker
could inject the authorization request and read the authorization response.
Although using request object signatures would provide mitigation, this profile does not require
request object signatures because of the lack of available implementations.<a href="#section-5.3-4" class="pilcrow">¶</a></p>
</section>
</section>
<section id="section-6">
<h2 id="name-privacy-considerations">
<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-privacy-considerations" class="section-name selfRef">Privacy Considerations</a>
</h2>
<p id="section-6-1">This profile addresses the privacy threats identified in <span><a href="#RFC6973" class="internal xref">Privacy Considerations for Internet Protocols</a> [<a href="#RFC6973" class="cite xref">RFC6973</a>]</span> with normative
language throughout the document. In particular, this profile requires the use of TLS for all network connections, PKCE, and sender constrained tokens
to mitigate the threats in <span>[<a href="#RFC6973" class="cite xref">RFC6973</a>]</span><a href="#section-6-1" class="pilcrow">¶</a></p>
<p id="section-6-2">In OpenID Connect implementations, cilents and servers SHOULD implement the privacy threat mitigations in Section 17 of
<span><a href="#OpenID.Core" class="internal xref">OpenID Connect Core 1.0</a> [<a href="#OpenID.Core" class="cite xref">OpenID.Core</a>]</span>.<a href="#section-6-2" class="pilcrow">¶</a></p>
</section>
<section id="section-7">
<h2 id="name-normative-references">
<a href="#section-7" class="section-number selfRef">7. </a><a href="#name-normative-references" class="section-name selfRef">Normative References</a>
</h2>
<dl class="references">
<dt id="BCP195">[BCP195]</dt>
<dd>
<span class="refAuthor">Sheffer, Y.</span>, <span class="refAuthor">Holz, R.</span>, and <span class="refAuthor">P. Saint-Andre</span>, <span class="refTitle">"Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)"</span>, <span class="seriesInfo">BCP 195</span>, <span class="seriesInfo">RFC 7525</span>, <span class="seriesInfo">DOI 10.17487/RFC7525</span>, <time datetime="2015-05" class="refDate">May 2015</time>, <span><<a href="http://www.rfc-editor.org/info/bcp195">http://www.rfc-editor.org/info/bcp195</a>></span>. </dd>
<dd class="break"></dd>
<dt id="BCP240">[BCP240]</dt>
<dd>
<span class="refAuthor">Lodderstedt, T.</span>, <span class="refAuthor">Bradley, J.</span>, <span class="refAuthor">Labunets, A.</span>, and <span class="refAuthor">D. Fett</span>, <span class="refTitle">"Best Current Practice for OAuth 2.0 Security"</span>, <span class="seriesInfo">BCP 240</span>, <span class="seriesInfo">RFC 9700</span>, <span class="seriesInfo">DOI 10.17487/RFC9700</span>, <time datetime="2025-01" class="refDate">January 2025</time>, <span><<a href="http://www.rfc-editor.org/info/bcp240">http://www.rfc-editor.org/info/bcp240</a>></span>. </dd>
<dd class="break"></dd>
<dt id="browser-based-apps">[browser-based-apps]</dt>
<dd>
<span class="refAuthor">Parecki, A.</span>, <span class="refAuthor">Waite, D.</span>, and <span class="refAuthor">P. De Ryck</span>, <span class="refTitle">"OAuth 2.0 for Browser-Based Applications"</span>, <time datetime="2025-01-17" class="refDate">17 January 2025</time>, <span><<a href="https://datatracker.ietf.org/doc/html/draft-ietf-oauth-browser-based-apps">https://datatracker.ietf.org/doc/html/draft-ietf-oauth-browser-based-apps</a>></span>. </dd>
<dd class="break"></dd>
<dt id="draft-resource-metadata">[draft-resource-metadata]</dt>
<dd>
<span class="refAuthor">Jones, M.</span>, <span class="refAuthor">Hunt, P.</span>, and <span class="refAuthor">A. Parecki</span>, <span class="refTitle">"OAuth 2.0 Protected Resource Metadata"</span>, <time datetime="2024-10-15" class="refDate">15 October 2024</time>, <span><<a href="https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-metadata/">https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-metadata/</a>></span>. </dd>
<dd class="break"></dd>
<dt id="JWS.JWE.Algs">[JWS.JWE.Algs]</dt>
<dd>
<span class="refTitle">"JSON Web Signature and Encryption Algorithms registry"</span>, <time datetime="2016-08-08" class="refDate">8 August 2016</time>. </dd>
<dd class="break"></dd>
<dt id="mlkem.ikev2">[mlkem.ikev2]</dt>
<dd>
<span class="refAuthor">Kampanakis, P.</span> and <span class="refAuthor">G. Ravago</span>, <span class="refTitle">"Post-quantum Hybrid Key Exchange with ML-KEM in the Internet Key Exchange Protocol Version 2 (IKEv2)"</span>, <time datetime="2024-11-04" class="refDate">4 November 2024</time>, <span><<a href="https://datatracker.ietf.org/doc/draft-kampanakis-ml-kem-ikev2/">https://datatracker.ietf.org/doc/draft-kampanakis-ml-kem-ikev2/</a>></span>. </dd>
<dd class="break"></dd>
<dt id="OpenID.Core">[OpenID.Core]</dt>
<dd>
<span class="refAuthor">Sakimura, N.</span>, <span class="refAuthor">Bradley, J.</span>, <span class="refAuthor">Jones, M.B.</span>, <span class="refAuthor">de Medeiros, B.</span>, and <span class="refAuthor">C. Mortimore</span>, <span class="refTitle">"OpenID Connect Core 1.0"</span>, <time datetime="2015-08-03" class="refDate">3 August 2015</time>, <span><<a href="http://openid.net/specs/openid-connect-core-1_0.html">http://openid.net/specs/openid-connect-core-1_0.html</a>></span>. </dd>
<dd class="break"></dd>
<dt id="OpenID.Discovery">[OpenID.Discovery]</dt>
<dd>
<span class="refAuthor">Sakimura, N.</span>, <span class="refAuthor">Bradley, J.</span>, <span class="refAuthor">Jones, M.B.</span>, and <span class="refAuthor">E. Jay</span>, <span class="refTitle">"OpenID Connect Discovery 1.0"</span>, <time datetime="2015-08-03" class="refDate">3 August 2015</time>, <span><<a href="http://openid.net/specs/openid-connect-discovery-1_0.html">http://openid.net/specs/openid-connect-discovery-1_0.html</a>></span>. </dd>
<dd class="break"></dd>
<dt id="OpenID.iGov">[OpenID.iGov]</dt>
<dd>
<span class="refAuthor">Varley, M.</span> and <span class="refAuthor">P. Grassi</span>, <span class="refTitle">"International Government Assurance Profile (iGov) for OpenID Connect 1.0"</span>, <time datetime="2023-08-03" class="refDate">3 August 2023</time>, <span><<a href="https://openid.net/specs/openid-igov-openid-connect-1_0.html">https://openid.net/specs/openid-igov-openid-connect-1_0.html</a>></span>. </dd>
<dd class="break"></dd>
<dt id="pkce-vs-nonce">[pkce-vs-nonce]</dt>
<dd>
<span class="refAuthor">Fett, D.</span>, <span class="refTitle">"PKCE vs. Nonce: Equivalent or Not?"</span>, <time datetime="2020-05-16" class="refDate">16 May 2020</time>, <span><<a href="https://danielfett.de/2020/05/16/pkce-vs-nonce-equivalent-or-not/">https://danielfett.de/2020/05/16/pkce-vs-nonce-equivalent-or-not/</a>></span>. </dd>
<dd class="break"></dd>
<dt id="RFC2119">[RFC2119]</dt>
<dd>
<span class="refAuthor">Bradner, S.</span>, <span class="refTitle">"Key words for use in RFCs to Indicate Requirement Levels"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 2119</span>, <span class="seriesInfo">DOI 10.17487/RFC2119</span>, <time datetime="1997-03" class="refDate">March 1997</time>, <span><<a href="https://www.rfc-editor.org/info/rfc2119">https://www.rfc-editor.org/info/rfc2119</a>></span>. </dd>
<dd class="break"></dd>
<dt id="RFC6749">[RFC6749]</dt>
<dd>
<span class="refAuthor">Hardt, D., Ed.</span>, <span class="refTitle">"The OAuth 2.0 Authorization Framework"</span>, <span class="seriesInfo">RFC 6749</span>, <span class="seriesInfo">DOI 10.17487/RFC6749</span>, <time datetime="2012-10" class="refDate">October 2012</time>, <span><<a href="https://www.rfc-editor.org/info/rfc6749">https://www.rfc-editor.org/info/rfc6749</a>></span>. </dd>
<dd class="break"></dd>
<dt id="RFC6750">[RFC6750]</dt>
<dd>
<span class="refAuthor">Jones, M.</span> and <span class="refAuthor">D. Hardt</span>, <span class="refTitle">"The OAuth 2.0 Authorization Framework: Bearer Token Usage"</span>, <span class="seriesInfo">RFC 6750</span>, <span class="seriesInfo">DOI 10.17487/RFC6750</span>, <time datetime="2012-10" class="refDate">October 2012</time>, <span><<a href="https://www.rfc-editor.org/info/rfc6750">https://www.rfc-editor.org/info/rfc6750</a>></span>. </dd>
<dd class="break"></dd>
<dt id="RFC6797">[RFC6797]</dt>
<dd>
<span class="refAuthor">Hodges, J.</span>, <span class="refAuthor">Jackson, C.</span>, and <span class="refAuthor">A. Barth</span>, <span class="refTitle">"HTTP Strict Transport Security (HSTS)"</span>, <span class="seriesInfo">RFC 6797</span>, <span class="seriesInfo">DOI 10.17487/RFC6797</span>, <time datetime="2012-11" class="refDate">November 2012</time>, <span><<a href="https://www.rfc-editor.org/info/rfc6797">https://www.rfc-editor.org/info/rfc6797</a>></span>. </dd>
<dd class="break"></dd>
<dt id="RFC6819">[RFC6819]</dt>
<dd>
<span class="refAuthor">Lodderstedt, T., Ed.</span>, <span class="refAuthor">McGloin, M.</span>, and <span class="refAuthor">P. Hunt</span>, <span class="refTitle">"OAuth 2.0 Threat Model and Security Considerations"</span>, <span class="seriesInfo">RFC 6819</span>, <span class="seriesInfo">DOI 10.17487/RFC6819</span>, <time datetime="2013-01" class="refDate">January 2013</time>, <span><<a href="https://www.rfc-editor.org/info/rfc6819">https://www.rfc-editor.org/info/rfc6819</a>></span>. </dd>
<dd class="break"></dd>
<dt id="RFC6973">[RFC6973]</dt>
<dd>
<span class="refAuthor">Cooper, A.</span>, <span class="refAuthor">Tschofenig, H.</span>, <span class="refAuthor">Aboba, B.</span>, <span class="refAuthor">Peterson, J.</span>, <span class="refAuthor">Morris, J.</span>, <span class="refAuthor">Hansen, M.</span>, and <span class="refAuthor">R. Smith</span>, <span class="refTitle">"Privacy Considerations for Internet Protocols"</span>, <span class="seriesInfo">RFC 6973</span>, <span class="seriesInfo">DOI 10.17487/RFC6973</span>, <time datetime="2013-07" class="refDate">July 2013</time>, <span><<a href="https://www.rfc-editor.org/info/rfc6973">https://www.rfc-editor.org/info/rfc6973</a>></span>. </dd>
<dd class="break"></dd>
<dt id="RFC7009">[RFC7009]</dt>
<dd>
<span class="refAuthor">Lodderstedt, T., Ed.</span>, <span class="refAuthor">Dronia, S.</span>, and <span class="refAuthor">M. Scurtescu</span>, <span class="refTitle">"OAuth 2.0 Token Revocation"</span>, <span class="seriesInfo">RFC 7009</span>, <span class="seriesInfo">DOI 10.17487/RFC7009</span>, <time datetime="2013-08" class="refDate">August 2013</time>, <span><<a href="https://www.rfc-editor.org/info/rfc7009">https://www.rfc-editor.org/info/rfc7009</a>></span>. </dd>
<dd class="break"></dd>
<dt id="RFC7515">[RFC7515]</dt>
<dd>
<span class="refAuthor">Jones, M.</span>, <span class="refAuthor">Bradley, J.</span>, and <span class="refAuthor">N. Sakimura</span>, <span class="refTitle">"JSON Web Signature (JWS)"</span>, <span class="seriesInfo">RFC 7515</span>, <span class="seriesInfo">DOI 10.17487/RFC7515</span>, <time datetime="2015-05" class="refDate">May 2015</time>, <span><<a href="https://www.rfc-editor.org/info/rfc7515">https://www.rfc-editor.org/info/rfc7515</a>></span>. </dd>
<dd class="break"></dd>
<dt id="RFC7516">[RFC7516]</dt>
<dd>
<span class="refAuthor">Jones, M.</span> and <span class="refAuthor">J. Hildebrand</span>, <span class="refTitle">"JSON Web Encryption (JWE)"</span>, <span class="seriesInfo">RFC 7516</span>, <span class="seriesInfo">DOI 10.17487/RFC7516</span>, <time datetime="2015-05" class="refDate">May 2015</time>, <span><<a href="https://www.rfc-editor.org/info/rfc7516">https://www.rfc-editor.org/info/rfc7516</a>></span>. </dd>
<dd class="break"></dd>
<dt id="RFC7517">[RFC7517]</dt>
<dd>
<span class="refAuthor">Jones, M.</span>, <span class="refTitle">"JSON Web Key (JWK)"</span>, <span class="seriesInfo">RFC 7517</span>, <span class="seriesInfo">DOI 10.17487/RFC7517</span>, <time datetime="2015-05" class="refDate">May 2015</time>, <span><<a href="https://www.rfc-editor.org/info/rfc7517">https://www.rfc-editor.org/info/rfc7517</a>></span>. </dd>
<dd class="break"></dd>
<dt id="RFC7518">[RFC7518]</dt>
<dd>
<span class="refAuthor">Jones, M.</span>, <span class="refTitle">"JSON Web Algorithms (JWA)"</span>, <span class="seriesInfo">RFC 7518</span>, <span class="seriesInfo">DOI 10.17487/RFC7518</span>, <time datetime="2015-05" class="refDate">May 2015</time>, <span><<a href="https://www.rfc-editor.org/info/rfc7518">https://www.rfc-editor.org/info/rfc7518</a>></span>. </dd>
<dd class="break"></dd>
<dt id="RFC7519">[RFC7519]</dt>
<dd>
<span class="refAuthor">Jones, M.</span>, <span class="refAuthor">Bradley, J.</span>, and <span class="refAuthor">N. Sakimura</span>, <span class="refTitle">"JSON Web Token (JWT)"</span>, <span class="seriesInfo">RFC 7519</span>, <span class="seriesInfo">DOI 10.17487/RFC7519</span>, <time datetime="2015-05" class="refDate">May 2015</time>, <span><<a href="https://www.rfc-editor.org/info/rfc7519">https://www.rfc-editor.org/info/rfc7519</a>></span>. </dd>
<dd class="break"></dd>
<dt id="RFC7523">[RFC7523]</dt>
<dd>
<span class="refAuthor">Jones, M.</span>, <span class="refAuthor">Campbell, B.</span>, and <span class="refAuthor">C. Mortimore</span>, <span class="refTitle">"JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants"</span>, <span class="seriesInfo">RFC 7523</span>, <span class="seriesInfo">DOI 10.17487/RFC7523</span>, <time datetime="2015-05" class="refDate">May 2015</time>, <span><<a href="https://www.rfc-editor.org/info/rfc7523">https://www.rfc-editor.org/info/rfc7523</a>></span>. </dd>
<dd class="break"></dd>
<dt id="RFC7591">[RFC7591]</dt>
<dd>
<span class="refAuthor">Richer, J., Ed.</span>, <span class="refAuthor">Jones, M.</span>, <span class="refAuthor">Bradley, J.</span>, <span class="refAuthor">Machulak, M.</span>, and <span class="refAuthor">P. Hunt</span>, <span class="refTitle">"OAuth 2.0 Dynamic Client Registration Protocol"</span>, <span class="seriesInfo">RFC 7591</span>, <span class="seriesInfo">DOI 10.17487/RFC7591</span>, <time datetime="2015-07" class="refDate">July 2015</time>, <span><<a href="https://www.rfc-editor.org/info/rfc7591">https://www.rfc-editor.org/info/rfc7591</a>></span>. </dd>
<dd class="break"></dd>
<dt id="RFC7636">[RFC7636]</dt>
<dd>
<span class="refAuthor">Sakimura, N., Ed.</span>, <span class="refAuthor">Bradley, J.</span>, and <span class="refAuthor">N. Agarwal</span>, <span class="refTitle">"Proof Key for Code Exchange by OAuth Public Clients"</span>, <span class="seriesInfo">RFC 7636</span>, <span class="seriesInfo">DOI 10.17487/RFC7636</span>, <time datetime="2015-09" class="refDate">September 2015</time>, <span><<a href="https://www.rfc-editor.org/info/rfc7636">https://www.rfc-editor.org/info/rfc7636</a>></span>. </dd>
<dd class="break"></dd>
<dt id="RFC7638">[RFC7638]</dt>
<dd>
<span class="refAuthor">Jones, M.</span> and <span class="refAuthor">N. Sakimura</span>, <span class="refTitle">"JSON Web Key (JWK) Thumbprint"</span>, <span class="seriesInfo">RFC 7638</span>, <span class="seriesInfo">DOI 10.17487/RFC7638</span>, <time datetime="2015-09" class="refDate">September 2015</time>, <span><<a href="https://www.rfc-editor.org/info/rfc7638">https://www.rfc-editor.org/info/rfc7638</a>></span>. </dd>
<dd class="break"></dd>
<dt id="RFC7662">[RFC7662]</dt>
<dd>
<span class="refAuthor">Richer, J., Ed.</span>, <span class="refTitle">"OAuth 2.0 Token Introspection"</span>, <span class="seriesInfo">RFC 7662</span>, <span class="seriesInfo">DOI 10.17487/RFC7662</span>, <time datetime="2015-10" class="refDate">October 2015</time>, <span><<a href="https://www.rfc-editor.org/info/rfc7662">https://www.rfc-editor.org/info/rfc7662</a>></span>. </dd>
<dd class="break"></dd>
<dt id="RFC7800">[RFC7800]</dt>
<dd>
<span class="refAuthor">Jones, M.</span>, <span class="refAuthor">Bradley, J.</span>, and <span class="refAuthor">H. Tschofenig</span>, <span class="refTitle">"Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)"</span>, <span class="seriesInfo">RFC 7800</span>, <span class="seriesInfo">DOI 10.17487/RFC7800</span>, <time datetime="2016-04" class="refDate">April 2016</time>, <span><<a href="https://www.rfc-editor.org/info/rfc7800">https://www.rfc-editor.org/info/rfc7800</a>></span>. </dd>
<dd class="break"></dd>
<dt id="RFC8252">[RFC8252]</dt>
<dd>
<span class="refAuthor">Denniss, W.</span> and <span class="refAuthor">J. Bradley</span>, <span class="refTitle">"OAuth 2.0 for Native Apps"</span>, <span class="seriesInfo">BCP 212</span>, <span class="seriesInfo">RFC 8252</span>, <span class="seriesInfo">DOI 10.17487/RFC8252</span>, <time datetime="2017-10" class="refDate">October 2017</time>, <span><<a href="https://www.rfc-editor.org/info/rfc8252">https://www.rfc-editor.org/info/rfc8252</a>></span>. </dd>
<dd class="break"></dd>
<dt id="RFC8414">[RFC8414]</dt>
<dd>
<span class="refAuthor">Jones, M.</span>, <span class="refAuthor">Sakimura, N.</span>, and <span class="refAuthor">J. Bradley</span>, <span class="refTitle">"OAuth 2.0 Authorization Server Metadata"</span>, <span class="seriesInfo">RFC 8414</span>, <span class="seriesInfo">DOI 10.17487/RFC8414</span>, <time datetime="2018-06" class="refDate">June 2018</time>, <span><<a href="https://www.rfc-editor.org/info/rfc8414">https://www.rfc-editor.org/info/rfc8414</a>></span>. </dd>
<dd class="break"></dd>
<dt id="RFC8705">[RFC8705]</dt>
<dd>
<span class="refAuthor">Campbell, B.</span>, <span class="refAuthor">Bradley, J.</span>, <span class="refAuthor">Sakimura, N.</span>, and <span class="refAuthor">T. Lodderstedt</span>, <span class="refTitle">"OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens"</span>, <span class="seriesInfo">RFC 8705</span>, <span class="seriesInfo">DOI 10.17487/RFC8705</span>, <time datetime="2020-02" class="refDate">February 2020</time>, <span><<a href="https://www.rfc-editor.org/info/rfc8705">https://www.rfc-editor.org/info/rfc8705</a>></span>. </dd>
<dd class="break"></dd>
<dt id="RFC8725">[RFC8725]</dt>
<dd>
<span class="refAuthor">Sheffer, Y.</span>, <span class="refAuthor">Hardt, D.</span>, and <span class="refAuthor">M. Jones</span>, <span class="refTitle">"JSON Web Token Best Current Practices"</span>, <span class="seriesInfo">BCP 225</span>, <span class="seriesInfo">RFC 8725</span>, <span class="seriesInfo">DOI 10.17487/RFC8725</span>, <time datetime="2020-02" class="refDate">February 2020</time>, <span><<a href="https://www.rfc-editor.org/info/rfc8725">https://www.rfc-editor.org/info/rfc8725</a>></span>. </dd>
<dd class="break"></dd>
<dt id="RFC9068">[RFC9068]</dt>
<dd>
<span class="refAuthor">Bertocci, V.</span>, <span class="refTitle">"JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"</span>, <span class="seriesInfo">RFC 9068</span>, <span class="seriesInfo">DOI 10.17487/RFC9068</span>, <time datetime="2021-10" class="refDate">October 2021</time>, <span><<a href="https://www.rfc-editor.org/info/rfc9068">https://www.rfc-editor.org/info/rfc9068</a>></span>. </dd>
<dd class="break"></dd>
<dt id="RFC9364">[RFC9364]</dt>
<dd>
<span class="refAuthor">Hoffman, P.</span>, <span class="refTitle">"DNS Security Extensions (DNSSEC)"</span>, <span class="seriesInfo">BCP 237</span>, <span class="seriesInfo">RFC 9364</span>, <span class="seriesInfo">DOI 10.17487/RFC9364</span>, <time datetime="2023-02" class="refDate">February 2023</time>, <span><<a href="https://www.rfc-editor.org/info/rfc9364">https://www.rfc-editor.org/info/rfc9364</a>></span>. </dd>
<dd class="break"></dd>
<dt id="RFC9449">[RFC9449]</dt>
<dd>
<span class="refAuthor">Fett, D.</span>, <span class="refAuthor">Campbell, B.</span>, <span class="refAuthor">Bradley, J.</span>, <span class="refAuthor">Lodderstedt, T.</span>, <span class="refAuthor">Jones, M.</span>, and <span class="refAuthor">D. Waite</span>, <span class="refTitle">"OAuth 2.0 Demonstrating Proof of Possession (DPoP)"</span>, <span class="seriesInfo">RFC 9449</span>, <span class="seriesInfo">DOI 10.17487/RFC9449</span>, <time datetime="2023-09" class="refDate">September 2023</time>, <span><<a href="https://www.rfc-editor.org/info/rfc9449">https://www.rfc-editor.org/info/rfc9449</a>></span>. </dd>
<dd class="break"></dd>
<dt id="RFC9470">[RFC9470]</dt>
<dd>
<span class="refAuthor">Bertocci, V.</span> and <span class="refAuthor">B. Campbell</span>, <span class="refTitle">"OAuth 2.0 Step Up Authentication Challenge Protocol"</span>, <span class="seriesInfo">RFC 9470</span>, <span class="seriesInfo">DOI 10.17487/RFC9470</span>, <time datetime="2023-09" class="refDate">September 2023</time>, <span><<a href="https://www.rfc-editor.org/info/rfc9470">https://www.rfc-editor.org/info/rfc9470</a>></span>. </dd>
<dd class="break"></dd>
</dl>
</section>
<div id="Acknowledgements">
<section id="appendix-A">
<h2 id="name-acknowledgements">
<a href="#appendix-A" class="section-number selfRef">Appendix A. </a><a href="#name-acknowledgements" class="section-name selfRef">Acknowledgements</a>
</h2>
<p id="appendix-A-1">The OpenID Community would like to thank the following people for
their contributions to this specification: Mark Russel, Mary
Pulvermacher, David Hill, Dale Moberg, Adrian Gropper, Eve Maler,
Danny van Leeuwen, John Moehrke, Aaron Seib, John Bradley, Debbie
Bucci, Josh Mandel, Sarah Cecchetti, Giuseppe De Marco, Joseph Heenan,
Jim Fenton, Ryan Galluzzo, Bjorn Hjelm, Aaron Parecki, and Michael B. Jones.<a href="#appendix-A-1" class="pilcrow">¶</a></p>
<p id="appendix-A-2"> Special thank you to the original iGov Profile editors: Paul Grassi, Justin Richer,
and Michael Varley.<a href="#appendix-A-2" class="pilcrow">¶</a></p>
<p id="appendix-A-3">The original version of this specification was part of the Secure
RESTful Interfaces project from The MITRE Corporation, available
online
at http://secure-restful-interface-profile.github.io/pages/<a href="#appendix-A-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="Notices">
<section id="appendix-B">
<h2 id="name-notices">
<a href="#appendix-B" class="section-number selfRef">Appendix B. </a><a href="#name-notices" class="section-name selfRef">Notices</a>
</h2>
<p id="appendix-B-1">Copyright (c) 2025 The OpenID Foundation.<a href="#appendix-B-1" class="pilcrow">¶</a></p>
<p id="appendix-B-2">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, Final Specification, or Final Specification Incorporating Errata Corrections solely for the
purposes of (i) developing specifications, and (ii) implementing Implementers Drafts, Final Specifications, and Final Specification Incorporating Errata Corrections 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.<a href="#appendix-B-2" class="pilcrow">¶</a></p>
<p id="appendix-B-3">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 (found at openid.net) requires contributors to offer a patent promise not to assert certain patent claims against other contributors and against implementers.
OpenID 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.<a href="#appendix-B-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="History">
<section id="appendix-C">
<h2 id="name-document-history">
<a href="#appendix-C" class="section-number selfRef">Appendix C. </a><a href="#name-document-history" class="section-name selfRef">Document History</a>
</h2>
<p id="appendix-C-1">[[ To be removed from the final specification ]]<a href="#appendix-C-1" class="pilcrow">¶</a></p>
<p id="appendix-C-2">
-05<a href="#appendix-C-2" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="appendix-C-3.1">
<p id="appendix-C-3.1.1">
Updated BCP mitigations, aligned with FAPI<a href="#appendix-C-3.1.1" class="pilcrow">¶</a></p>
</li>
<li class="normal" id="appendix-C-3.2">
<p id="appendix-C-3.2.1">
Harmonized cryptography, sender constrained tokens with FAPI<a href="#appendix-C-3.2.1" class="pilcrow">¶</a></p>
</li>
<li class="normal" id="appendix-C-3.3">
<p id="appendix-C-3.3.1">
Added requirement and optionality for authentication context and support for Step-up (RFC 9470)<a href="#appendix-C-3.3.1" class="pilcrow">¶</a></p>
</li>
<li class="normal" id="appendix-C-3.4">
<p id="appendix-C-3.4.1">
Added Privacy Considerations (RFC 6973)<a href="#appendix-C-3.4.1" class="pilcrow">¶</a></p>
</li>
<li class="normal" id="appendix-C-3.5">
<p id="appendix-C-3.5.1">
Added optionality to support enterprise tailoring, especially RFC 8705 mTLS with PKI<a href="#appendix-C-3.5.1" class="pilcrow">¶</a></p>
</li>
</ul>
<p id="appendix-C-4">
-04<a href="#appendix-C-4" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="appendix-C-5.1">
<p id="appendix-C-5.1.1">
Enable building with https://author-tools.ietf.org/.<a href="#appendix-C-5.1.1" class="pilcrow">¶</a></p>
</li>
<li class="normal" id="appendix-C-5.2">
<p id="appendix-C-5.2.1">
Applied OpenID specification conventions.<a href="#appendix-C-5.2.1" class="pilcrow">¶</a></p>
</li>
</ul>
<p id="appendix-C-6">
-03<a href="#appendix-C-6" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="appendix-C-7.1">
<p id="appendix-C-7.1.1">
First Implementer's Draft<a href="#appendix-C-7.1.1" class="pilcrow">¶</a></p>
</li>
</ul>
<p id="appendix-C-8">-2017-06-01<a href="#appendix-C-8" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="appendix-C-9.1">
<p id="appendix-C-9.1.1">Aligned with prior version of iGov.<a href="#appendix-C-9.1.1" class="pilcrow">¶</a></p>
</li>
<li class="normal" id="appendix-C-9.2">
<p id="appendix-C-9.2.1">Added guidance text around using scopes and refresh_tokens to protect sensitive resources.<a href="#appendix-C-9.2.1" class="pilcrow">¶</a></p>
</li>
<li class="normal" id="appendix-C-9.3">
<p id="appendix-C-9.3.1">Removed ACR reference.<a href="#appendix-C-9.3.1" class="pilcrow">¶</a></p>
</li>
</ul>
<p id="appendix-C-10">-2018-05-07<a href="#appendix-C-10" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="appendix-C-11.1">
<p id="appendix-C-11.1.1">Imported content from HEART OAuth profile.<a href="#appendix-C-11.1.1" class="pilcrow">¶</a></p>
</li>
</ul>
</section>
</div>
<div id="authors-addresses">
<section id="appendix-D">
<h2 id="name-authors-addresses">
<a href="#name-authors-addresses" class="section-name selfRef">Authors' Addresses</a>
</h2>
<address class="vcard">
<div dir="auto" class="left"><span class="fn nameRole">Kelley Burgin (<span class="role">editor</span>)</span></div>
<div dir="auto" class="left"><span class="org">The MITRE Corporation</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:kburgin@mitre.org" class="email">kburgin@mitre.org</a>
</div>
</address>
<address class="vcard">
<div dir="auto" class="left"><span class="fn nameRole">Tom Clancy (<span class="role">editor</span>)</span></div>
<div dir="auto" class="left"><span class="org">The MITRE Corporation</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:tclancy@mitre.org" class="email">tclancy@mitre.org</a>
</div>
</address>
</section>
</div>
<script>const toc = document.getElementById("toc");
toc.querySelector("h2").addEventListener("click", e => {
toc.classList.toggle("active");
});
toc.querySelector("nav").addEventListener("click", e => {
toc.classList.remove("active");
});
</script>
</body>
</html>