File: rfc9068.html

package info (click to toggle)
doc-rfc 20230121-1
links: PTS, VCS
area: non-free
in suites: bookworm, forky, sid, trixie
size: 1,609,944 kB
file content (2162 lines) | stat: -rw-r--r-- 104,974 bytes
<!DOCTYPE html>
<html lang="en" class="RFC">
<head>
<meta charset="utf-8">
<meta content="Common,Latin" name="scripts">
<meta content="initial-scale=1.0" name="viewport">
<title>RFC 9068: JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens</title>
<meta content="Vittorio Bertocci" name="author">
<meta content="
       
        This specification defines a profile for issuing OAuth 2.0 access tokens in JSON Web Token (JWT) format. Authorization 
servers
 and resource servers from different vendors can leverage this profile to issue and consume access tokens in an interoperable manner.  
       
    " name="description">
<meta content="xml2rfc 3.10.0" name="generator">
<meta content="OAuth" name="keyword">
<meta content="Resource" name="keyword">
<meta content="Access token" name="keyword">
<meta content="JWT" name="keyword">
<meta content="9068" name="rfc.number">
<!-- Generator version information:
  xml2rfc 3.10.0
    Python 3.6.13
    appdirs 1.4.4
    ConfigArgParse 1.4.1
    google-i18n-address 2.4.0
    html5lib 1.0.1
    intervaltree 3.0.2
    Jinja2 2.11.3
    kitchen 1.2.6
    lxml 4.4.2
    pycairo 1.15.1
    pycountry 19.8.18
    pyflakes 2.1.1
    PyYAML 5.4.1
    requests 2.24.0
    setuptools 40.5.0
    six 1.14.0
    WeasyPrint 52.5
-->
<link href="rfc9068.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 necssary 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 */

@viewport {
  zoom: 1.0;
  width: extend-to-zoom;
}
@-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: 'Noto Sans', Arial, Helvetica, sans-serif;
  line-height: 1.6;
  scroll-behavior: smooth;
}
.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;
}
.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 {
  border: none;
  /* this isn't optimal, but it's an existence proof.  PrinceXML doesn't
     support flexbox yet.
  */
  display: table;
  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, code {
  background-color: #f9f9f9;
  font-family: 'Roboto Mono', monospace;
}
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;
}
cite {
  display: block;
  text-align: right;
  font-style: italic;
}

/* 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 {
    float: none;
  }
}
#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;
}

.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: "Noto Sans",Arial,Helvetica,sans-serif;
  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;
  }
  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 follwing 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, code {
  font-size: 95%;
}

/* Fix the height/width aspect for ascii art*/
pre.sourcecode,
.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 informatio 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,
  .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: lower-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 sligthtly */
table {
  border: 1px solid #ddd;
}
td {
  border-top: 1px solid #ddd;
}
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 bottim 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 {
  background-color: #f8f8f8;
}
/* Tweak the pre margin -- 0px doesn't come out well */
pre {
   margin-top: 0.5px;
}
/* Tweak the comact 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:first-child > pre.sourcecode,
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 {
  margin-bottom: 0;
}
</style>
<link href="rfc-local.css" rel="stylesheet" type="text/css">
<link href="https://dx.doi.org/10.17487/rfc9068" rel="alternate">
  <link href="urn:issn:2070-1721" rel="alternate">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-oauth-access-token-jwt-13" rel="prev">
  </head>
<body>
<script src="https://www.rfc-editor.org/js/metadata.min.js"></script>
<table class="ears">
<thead><tr>
<td class="left">RFC 9068</td>
<td class="center">OAuth 2.0 Access Token JWT Profile</td>
<td class="right">October 2021</td>
</tr></thead>
<tfoot><tr>
<td class="left">Bertocci</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-stream">Stream:</dt>
<dd class="stream">Internet Engineering Task Force (IETF)</dd>
<dt class="label-rfc">RFC:</dt>
<dd class="rfc"><a href="https://www.rfc-editor.org/rfc/rfc9068" class="eref">9068</a></dd>
<dt class="label-category">Category:</dt>
<dd class="category">Standards Track</dd>
<dt class="label-published">Published:</dt>
<dd class="published">
<time datetime="2021-10" class="published">October 2021</time>
    </dd>
<dt class="label-issn">ISSN:</dt>
<dd class="issn">2070-1721</dd>
<dt class="label-authors">Author:</dt>
<dd class="authors">
<div class="author">
      <div class="author-name">V. Bertocci</div>
<div class="org">Auth0</div>
</div>
</dd>
</dl>
</div>
<h1 id="rfcnum">RFC 9068</h1>
<h1 id="title">JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens</h1>
<section id="section-abstract">
      <h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
<p id="section-abstract-1">
        This specification defines a profile for issuing OAuth 2.0 access tokens in JSON Web Token (JWT) format. Authorization 
servers
 and resource servers from different vendors can leverage this profile to issue and consume access tokens in an interoperable manner.<a href="#section-abstract-1" class="pilcrow">¶</a></p>
</section>
<div id="status-of-memo">
<section id="section-boilerplate.1">
        <h2 id="name-status-of-this-memo">
<a href="#name-status-of-this-memo" class="section-name selfRef">Status of This Memo</a>
        </h2>
<p id="section-boilerplate.1-1">
            This is an Internet Standards Track document.<a href="#section-boilerplate.1-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.1-2">
            This document is a product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by
            the Internet Engineering Steering Group (IESG).  Further
            information on Internet Standards is available in Section 2 of 
            RFC 7841.<a href="#section-boilerplate.1-2" class="pilcrow">¶</a></p>
<p id="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <span><a href="https://www.rfc-editor.org/info/rfc9068">https://www.rfc-editor.org/info/rfc9068</a></span>.<a href="#section-boilerplate.1-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="copyright">
<section id="section-boilerplate.2">
        <h2 id="name-copyright-notice">
<a href="#name-copyright-notice" class="section-name selfRef">Copyright Notice</a>
        </h2>
<p id="section-boilerplate.2-1">
            Copyright (c) 2021 IETF Trust and the persons identified as the
            document authors. All rights reserved.<a href="#section-boilerplate.2-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<span><a href="https://trustee.ietf.org/license-info">https://trustee.ietf.org/license-info</a></span>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document. Code Components extracted from this
            document must include Simplified BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Simplified BSD License.<a href="#section-boilerplate.2-2" class="pilcrow">¶</a></p>
</section>
</div>
<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" class="keepWithNext"><a href="#section-1" class="xref">1</a>.  <a href="#name-introduction" class="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="xref">1.1</a>.  <a href="#name-requirements-notation-and-c" class="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="xref">1.2</a>.  <a href="#name-terminology" class="xref">Terminology</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="xref">2</a>.  <a href="#name-jwt-access-token-header-and" class="xref">JWT Access Token Header and Data Structure</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="xref">2.1</a>.  <a href="#name-header" class="xref">Header</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="xref">2.2</a>.  <a href="#name-data-structure" class="xref">Data Structure</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2.2.2.2.1">
                    <p id="section-toc.1-1.2.2.2.2.1.1"><a href="#section-2.2.1" class="xref">2.2.1</a>.  <a href="#name-authentication-information-" class="xref">Authentication Information Claims</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2.2.2.2.2">
                    <p id="section-toc.1-1.2.2.2.2.2.1"><a href="#section-2.2.2" class="xref">2.2.2</a>.  <a href="#name-identity-claims" class="xref">Identity Claims</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2.2.2.2.3">
                    <p id="section-toc.1-1.2.2.2.2.3.1"><a href="#section-2.2.3" class="xref">2.2.3</a>.  <a href="#name-authorization-claims" class="xref">Authorization Claims</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2.2.2.2.3.2.1">
                        <p id="section-toc.1-1.2.2.2.2.3.2.1.1"><a href="#section-2.2.3.1" class="xref">2.2.3.1</a>.  <a href="#name-claims-for-authorization-ou" class="xref">Claims for Authorization Outside of Delegation Scenarios</a></p>
</li>
                    </ul>
</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="xref">3</a>.  <a href="#name-requesting-a-jwt-access-tok" class="xref">Requesting a JWT Access Token</a></p>
</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="xref">4</a>.  <a href="#name-validating-jwt-access-token" class="xref">Validating JWT Access Tokens</a></p>
</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="xref">5</a>.  <a href="#name-security-considerations" class="xref">Security Considerations</a></p>
</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="xref">6</a>.  <a href="#name-privacy-considerations" class="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="xref">7</a>.  <a href="#name-iana-considerations" class="xref">IANA Considerations</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.7.2.1">
                <p id="section-toc.1-1.7.2.1.1"><a href="#section-7.1" class="xref">7.1</a>.  <a href="#name-media-type-registration" class="xref">Media Type Registration</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.7.2.1.2.1">
                    <p id="section-toc.1-1.7.2.1.2.1.1"><a href="#section-7.1.1" class="xref">7.1.1</a>.  <a href="#name-registry-content" class="xref">Registry Content</a></p>
</li>
                </ul>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.7.2.2">
                <p id="section-toc.1-1.7.2.2.1"><a href="#section-7.2" class="xref">7.2</a>.  <a href="#name-claims-registration" class="xref">Claims Registration</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.7.2.2.2.1">
                    <p id="section-toc.1-1.7.2.2.2.1.1"><a href="#section-7.2.1" class="xref">7.2.1</a>.  <a href="#name-registry-content-2" class="xref">Registry Content</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.7.2.2.2.1.2.1">
                        <p id="section-toc.1-1.7.2.2.2.1.2.1.1"><a href="#section-7.2.1.1" class="xref">7.2.1.1</a>.  <a href="#name-roles" class="xref">Roles</a></p>
</li>
                      <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.7.2.2.2.1.2.2">
                        <p id="section-toc.1-1.7.2.2.2.1.2.2.1"><a href="#section-7.2.1.2" class="xref">7.2.1.2</a>.  <a href="#name-groups" class="xref">Groups</a></p>
</li>
                      <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.7.2.2.2.1.2.3">
                        <p id="section-toc.1-1.7.2.2.2.1.2.3.1"><a href="#section-7.2.1.3" class="xref">7.2.1.3</a>.  <a href="#name-entitlements" class="xref">Entitlements</a></p>
</li>
                    </ul>
</li>
                </ul>
</li>
            </ul>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8">
            <p id="section-toc.1-1.8.1"><a href="#section-8" class="xref">8</a>.  <a href="#name-references" class="xref">References</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8.2.1">
                <p id="section-toc.1-1.8.2.1.1"><a href="#section-8.1" class="xref">8.1</a>.  <a href="#name-normative-references" class="xref">Normative References</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8.2.2">
                <p id="section-toc.1-1.8.2.2.1"><a href="#section-8.2" class="xref">8.2</a>.  <a href="#name-informative-references" class="xref">Informative References</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.9">
            <p id="section-toc.1-1.9.1"><a href="#appendix-A" class="xref"></a><a href="#name-acknowledgements" class="xref">Acknowledgements</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-B" class="xref"></a><a href="#name-authors-address" class="xref">Author's Address</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">
  The original 
                <span><a href="#RFC6749" class="xref">OAuth 2.0 Authorization Framework</a> [<a href="#RFC6749" class="xref">RFC6749</a>]</span> specification does not mandate any specific format for access tokens. 
  While that remains perfectly appropriate for many important scenarios, in-market use has shown that many commercial OAuth 2.0 
  implementations elected to issue access tokens using a format that can be parsed and validated by resource servers directly, without further authorization server involvement. 
  The approach is particularly common in topologies where the authorization server and resource server are not co-located, 
  are not run by the same entity, or are otherwise separated by some boundary. At the time of writing, many commercial implementations leverage the 
                <span><a href="#RFC7519" class="xref">JSON Web Token (JWT)</a> [<a href="#RFC7519" class="xref">RFC7519</a>]</span> format.<a href="#section-1-1" class="pilcrow">¶</a></p>
<p id="section-1-2">
  Many vendor-specific JWT access tokens share the same functional layout, using JWT claims to convey the information needed to support a common set of use cases: token validation, transporting authorization information in the form of scopes and entitlements,
  carrying identity information about the subject, and so on. The differences are mostly confined to the claim names and syntax 
  used to represent the same entities, suggesting that interoperability could be easily achieved by standardizing a common set of claims and validation rules.<a href="#section-1-2" class="pilcrow">¶</a></p>
<p id="section-1-3">
  The assumption that access tokens are associated with specific information doesn't appear only in commercial implementations. 
  Various specifications in the OAuth 2.0 family (such as 
                <span><a href="#RFC8707" class="xref">resource indicators</a> [<a href="#RFC8707" class="xref">RFC8707</a>]</span>, 
                <span><a href="#RFC6750" class="xref">OAuth 2.0 bearer token usage</a> [<a href="#RFC6750" class="xref">RFC6750</a>]</span>, and others) postulate the presence of scoping mechanisms, such as an audience, in access tokens. 
The family of specifications associated with introspection also indirectly 
  suggests a fundamental set of information that access tokens are expected to carry or at least be associated with.<a href="#section-1-3" class="pilcrow">¶</a></p>
<p id="section-1-4">
 This specification aims to provide a standardized and interoperable profile as an alternative to the proprietary JWT access token layouts going forward. 
 Besides defining a common set of mandatory and optional claims, the profile provides clear indications on how authorization request 
 parameters determine the content of the issued JWT access token, how an authorization server can publish metadata relevant to the 
 JWT access tokens it issues, and how a resource server should validate incoming JWT access tokens.<a href="#section-1-4" class="pilcrow">¶</a></p>
<p id="section-1-5">
  Finally, this specification provides security and privacy considerations meant to prevent common mistakes and anti-patterns 
that are likely to occur in naive use of the JWT format to represent access tokens.<a href="#section-1-5" class="pilcrow">¶</a></p>
<p style="margin-left: 1.5em" id="section-1-6">
        Please note: Although both this document and <span>[<a href="#RFC7523" class="xref">RFC7523</a>]</span> use JSON Web Tokens in the context of the OAuth2 framework, the two specifications differ in both intent and mechanics. Whereas <span>[<a href="#RFC7523" class="xref">RFC7523</a>]</span> defines how a JWT Bearer Token can be used to request an access token, this document describes how to encode access tokens in JWT format.<a href="#section-1-6" class="pilcrow">¶</a></p>
<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 "<span class="bcp14">MUST</span>", "<span class="bcp14">MUST NOT</span>", "<span class="bcp14">REQUIRED</span>", "<span class="bcp14">SHALL</span>", "<span class="bcp14">SHALL NOT</span>", "<span class="bcp14">SHOULD</span>", "<span class="bcp14">SHOULD NOT</span>", "<span class="bcp14">RECOMMENDED</span>", "<span class="bcp14">NOT RECOMMENDED</span>",
    "<span class="bcp14">MAY</span>", and "<span class="bcp14">OPTIONAL</span>" in this document are to be interpreted as
    described in BCP 14 <span>[<a href="#RFC2119" class="xref">RFC2119</a>]</span> <span>[<a href="#RFC8174" class="xref">RFC8174</a>]</span> 
    when, and only when, they appear in all capitals, as shown here.<a href="#section-1.1-1" 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>
<span class="break"></span><dl class="dlParallel" id="section-1.2-1">
          <dt id="section-1.2-1.1">JWT access token:</dt>
          <dd style="margin-left: 1.5em" id="section-1.2-1.2"> 
        An OAuth 2.0 access token encoded in JWT format and complying with the requirements described in this specification.<a href="#section-1.2-1.2" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
<p id="section-1.2-2">
        This specification uses the terms
        "access token",
        "refresh token",
        "authorization server",
        "resource server",
        "authorization endpoint",
        "authorization request",
        "authorization response",
        "token endpoint",
        "grant type",
        "access token request",
        "access token response",
        and "client"
        defined by  
                    <span><a href="#RFC6749" class="xref">The OAuth 2.0 Authorization Framework</a> [<a href="#RFC6749" class="xref">RFC6749</a>]</span>.<a href="#section-1.2-2" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="JWTATLayout">
<section id="section-2">
      <h2 id="name-jwt-access-token-header-and">
<a href="#section-2" class="section-number selfRef">2. </a><a href="#name-jwt-access-token-header-and" class="section-name selfRef">JWT Access Token Header and Data Structure</a>
      </h2>
<div id="JWTATHeader">
<section id="section-2.1">
        <h3 id="name-header">
<a href="#section-2.1" class="section-number selfRef">2.1. </a><a href="#name-header" class="section-name selfRef">Header</a>
        </h3>
<p id="section-2.1-1">
 JWT access tokens <span class="bcp14">MUST</span> be signed. Although JWT access tokens can use any signing algorithm, use of asymmetric cryptography is <span class="bcp14">RECOMMENDED</span> as it simplifies the process of acquiring validation information for resource servers (see 
                    <a href="#JWTATLValidate" class="xref">Section 4</a>). JWT access tokens <span class="bcp14">MUST NOT</span> use "none" as the signing algorithm. See 
                    <a href="#JWTATLValidate" class="xref">Section 4</a> for more details.<a href="#section-2.1-1" class="pilcrow">¶</a></p>
<p id="section-2.1-2">
                Authorization servers and resource servers conforming to this specification <span class="bcp14">MUST</span> include RS256 (as defined in <span>[<a href="#RFC7518" class="xref">RFC7518</a>]</span>) among their supported signature algorithms.<a href="#section-2.1-2" class="pilcrow">¶</a></p>
<p id="section-2.1-3">
            
This specification registers the "application/at+jwt" media type, which can be used to indicate that the content is a JWT access token. 
   JWT access tokens <span class="bcp14">MUST</span> include this media type in the "typ" header parameter to explicitly declare that the JWT represents an access token complying with this profile.
   Per the definition of "typ" in <span><a href="https://www.rfc-editor.org/rfc/rfc7515#section-4.1.9" class="relref">Section 4.1.9</a> of [<a href="#RFC7515" class="xref">RFC7515</a>]</span>, it is <span class="bcp14">RECOMMENDED</span> that the "application/" prefix be omitted.  Therefore, the "typ" value used <span class="bcp14">SHOULD</span> be "at+jwt".
 See the <a href="#SecurityConsiderations" class="xref">Security Considerations</a> section for details on the importance of preventing OpenID Connect ID Tokens (as defined by Section 2 of <span>[<a href="#OpenID.Core" class="xref">OpenID.Core</a>]</span>) from being accepted as access tokens by resource servers implementing this profile.<a href="#section-2.1-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="JWTATDataStructure">
<section id="section-2.2">
        <h3 id="name-data-structure">
<a href="#section-2.2" class="section-number selfRef">2.2. </a><a href="#name-data-structure" class="section-name selfRef">Data Structure</a>
        </h3>
<p id="section-2.2-1">
 The following claims are used in the JWT access token data structure.<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">iss</dt>
          <dd style="margin-left: 1.5em" id="section-2.2-2.2">
            <span class="bcp14">REQUIRED</span> - as defined in <span><a href="https://www.rfc-editor.org/rfc/rfc7519#section-4.1.1" class="relref">Section 4.1.1</a> of [<a href="#RFC7519" class="xref">RFC7519</a>]</span>.<a href="#section-2.2-2.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.2-2.3">exp</dt>
          <dd style="margin-left: 1.5em" id="section-2.2-2.4">
            <span class="bcp14">REQUIRED</span> - as defined in <span><a href="https://www.rfc-editor.org/rfc/rfc7519#section-4.1.4" class="relref">Section 4.1.4</a> of [<a href="#RFC7519" class="xref">RFC7519</a>]</span>.<a href="#section-2.2-2.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.2-2.5">aud</dt>
          <dd style="margin-left: 1.5em" id="section-2.2-2.6">
            <span class="bcp14">REQUIRED</span> - as defined in <span><a href="https://www.rfc-editor.org/rfc/rfc7519#section-4.1.3" class="relref">Section 4.1.3</a> of [<a href="#RFC7519" class="xref">RFC7519</a>]</span>. See 
                            <a href="#JWTATLRequest" class="xref">Section 3</a> for indications on how an authorization server should determine the value of "aud" depending on the request.<a href="#section-2.2-2.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.2-2.7">sub</dt>
          <dd style="margin-left: 1.5em" id="section-2.2-2.8">
            <span class="bcp14">REQUIRED</span> - as defined in <span><a href="https://www.rfc-editor.org/rfc/rfc7519#section-4.1.2" class="relref">Section 4.1.2</a> of [<a href="#RFC7519" class="xref">RFC7519</a>]</span>. In cases of access tokens obtained through grants where a resource owner is involved, such as the authorization code grant, the value of "sub" <span class="bcp14">SHOULD</span> correspond to the subject identifier of the resource owner. In cases of access tokens obtained through grants where no resource owner is involved, such as the client credentials grant, the value of "sub" <span class="bcp14">SHOULD</span> correspond to an identifier the authorization server uses to indicate the client application. 
                            See 
                            <a href="#SecurityConsiderations" class="xref">Section 5</a> for more details on this scenario. Also, see 
                            <a href="#PrivacyConsiderations" class="xref">Section 6</a> for a discussion about how different choices in assigning "sub" values can impact privacy.<a href="#section-2.2-2.8" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.2-2.9">client_id</dt>
          <dd style="margin-left: 1.5em" id="section-2.2-2.10">
            <span class="bcp14">REQUIRED</span> - as defined in <span><a href="https://www.rfc-editor.org/rfc/rfc8693#section-4.3" class="relref">Section 4.3</a> of [<a href="#RFC8693" class="xref">RFC8693</a>]</span>.<a href="#section-2.2-2.10" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.2-2.11">iat</dt>
          <dd style="margin-left: 1.5em" id="section-2.2-2.12">
            <span class="bcp14">REQUIRED</span> - as defined in <span><a href="https://www.rfc-editor.org/rfc/rfc7519#section-4.1.6" class="relref">Section 4.1.6</a> of [<a href="#RFC7519" class="xref">RFC7519</a>]</span>.
 This claim identifies the time at which the JWT access token was issued.<a href="#section-2.2-2.12" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.2-2.13">jti</dt>
          <dd style="margin-left: 1.5em" id="section-2.2-2.14">
            <span class="bcp14">REQUIRED</span> - as defined in <span><a href="https://www.rfc-editor.org/rfc/rfc7519#section-4.1.7" class="relref">Section 4.1.7</a> of [<a href="#RFC7519" class="xref">RFC7519</a>]</span>.<a href="#section-2.2-2.14" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
<div id="AuthenticationInfoClaims">
<section id="section-2.2.1">
          <h4 id="name-authentication-information-">
<a href="#section-2.2.1" class="section-number selfRef">2.2.1. </a><a href="#name-authentication-information-" class="section-name selfRef">Authentication Information Claims</a>
          </h4>
<p id="section-2.2.1-1">The claims listed in this section <span class="bcp14">MAY</span> be issued in the context of authorization grants involving the resource owner and reflect the types and strength of authentication in the access token that the authentication server enforced prior to returning the authorization response to the client. Their values are fixed and remain the same across all access tokens that derive from a given authorization response, whether the access token was obtained directly 
                        in the response (e.g., via the implicit flow) or after one or more token exchanges (e.g., obtaining a fresh access token using a refresh token or exchanging one access token for another via 
                        <span>[<a href="#RFC8693" class="xref">RFC8693</a>]</span> procedures).<a href="#section-2.2.1-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-2.2.1-2">
            <dt id="section-2.2.1-2.1">auth_time</dt>
            <dd style="margin-left: 1.5em" id="section-2.2.1-2.2">
              <span class="bcp14">OPTIONAL</span> - as defined in Section 2 of 
                                <span>[<a href="#OpenID.Core" class="xref">OpenID.Core</a>]</span>.<a href="#section-2.2.1-2.2" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-2.2.1-2.3">acr</dt>
            <dd style="margin-left: 1.5em" id="section-2.2.1-2.4">
              <span class="bcp14">OPTIONAL</span> - as defined in Section 2 of 
                                <span>[<a href="#OpenID.Core" class="xref">OpenID.Core</a>]</span>.<a href="#section-2.2.1-2.4" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-2.2.1-2.5">amr</dt>
            <dd style="margin-left: 1.5em" id="section-2.2.1-2.6">
              <span class="bcp14">OPTIONAL</span> - as defined in Section 2 of 
                                <span>[<a href="#OpenID.Core" class="xref">OpenID.Core</a>]</span>.<a href="#section-2.2.1-2.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
</dl>
</section>
</div>
<div id="IdentityClaims">
<section id="section-2.2.2">
          <h4 id="name-identity-claims">
<a href="#section-2.2.2" class="section-number selfRef">2.2.2. </a><a href="#name-identity-claims" class="section-name selfRef">Identity Claims</a>
          </h4>
<p id="section-2.2.2-1">
 In the context of authorization grants involving the resource owner, commercial authorization servers will often include resource owner attributes directly in access tokens so that resource servers can consume them directly for authorization or other purposes without any further round trips to introspection (<span>[<a href="#RFC7662" class="xref">RFC7662</a>]</span>) or UserInfo (<span>[<a href="#OpenID.Core" class="xref">OpenID.Core</a>]</span>) endpoints.
 This is particularly common in scenarios where the client and the resource server belong to the same entity and are part of the same solution, as is the case for first-party clients invoking their own backend API.<a href="#section-2.2.2-1" class="pilcrow">¶</a></p>
<p id="section-2.2.2-2">This profile does not introduce any mechanism for a client to directly request the presence of specific claims in JWT access tokens, as the authorization server can determine what additional claims are required by a particular resource server by taking the client_id of the client and the "scope" and the "resource" parameters included in the request into consideration.<a href="#section-2.2.2-2" class="pilcrow">¶</a></p>
<p id="section-2.2.2-3">
                    Any additional identity attribute whose semantic is well described by an entry in the "JSON Web Token (JWT)" IANA registry introduced in <span>[<a href="#RFC7519" class="xref">RFC7519</a>]</span> <span class="bcp14">SHOULD</span> be encoded using the corresponding claim name, if that attribute is to be included in the JWT access token. Note that the JWT IANA registry includes the claims found in Section 5.1 of <span>[<a href="#OpenID.Core" class="xref">OpenID.Core</a>]</span>.<a href="#section-2.2.2-3" class="pilcrow">¶</a></p>
<p id="section-2.2.2-4">Authorization servers <span class="bcp14">MAY</span> return arbitrary attributes not defined in any existing specification, as long as the corresponding claim names are collision resistant or the access tokens are meant to be used only within a private subsystem. Please refer to Sections <a href="https://www.rfc-editor.org/rfc/rfc7519#section-4.2" class="relref">4.2</a> and <a href="https://www.rfc-editor.org/rfc/rfc7519#section-4.3" class="relref">4.3</a> of <span>[<a href="#RFC7519" class="xref">RFC7519</a>]</span> for details.<a href="#section-2.2.2-4" class="pilcrow">¶</a></p>
<p id="section-2.2.2-5">Authorization servers including resource owner attributes in JWT access tokens need to exercise care and verify that all privacy requirements are met, as discussed in 
                        
                        
                        
                        <a href="#PrivacyConsiderations" class="xref">Section 6</a>.<a href="#section-2.2.2-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="AuthorizationClaims">
<section id="section-2.2.3">
          <h4 id="name-authorization-claims">
<a href="#section-2.2.3" class="section-number selfRef">2.2.3. </a><a href="#name-authorization-claims" class="section-name selfRef">Authorization Claims</a>
          </h4>
<p id="section-2.2.3-1">
 If an authorization request includes a scope parameter, the corresponding issued JWT access token <span class="bcp14">SHOULD</span> include a "scope" claim as defined in  <span><a href="https://www.rfc-editor.org/rfc/rfc8693#section-4.2" class="relref">Section 4.2</a> of [<a href="#RFC8693" class="xref">RFC8693</a>]</span>.<a href="#section-2.2.3-1" class="pilcrow">¶</a></p>
<p id="section-2.2.3-2">
 All the individual scope strings in the "scope" claim <span class="bcp14">MUST</span> have meaning for the resources indicated in the "aud" claim. See 
                        <a href="#SecurityConsiderations" class="xref">Section 5</a> for more considerations about the relationship between scope strings and resources indicated by the "aud" claim.<a href="#section-2.2.3-2" class="pilcrow">¶</a></p>
<div id="NDAuthorizationClaims">
<section id="section-2.2.3.1">
            <h5 id="name-claims-for-authorization-ou">
<a href="#section-2.2.3.1" class="section-number selfRef">2.2.3.1. </a><a href="#name-claims-for-authorization-ou" class="section-name selfRef">Claims for Authorization Outside of Delegation Scenarios</a>
            </h5>
<p id="section-2.2.3.1-1">
 Many authorization servers embed authorization attributes that go beyond the delegated scenarios described by 
                            <span>[<a href="#RFC7519" class="xref">RFC7519</a>]</span> in the access tokens they issue. Typical examples include resource owner memberships in roles and groups that are relevant to the resource being accessed, entitlements assigned to the resource owner for the targeted resource that the authorization server knows about, and so on.<a href="#section-2.2.3.1-1" class="pilcrow">¶</a></p>
<p id="section-2.2.3.1-2">
An authorization server wanting to include such attributes in a JWT access token <span class="bcp14">SHOULD</span> use the "groups", "roles", and "entitlements" attributes of the "User" resource schema defined by <span><a href="https://www.rfc-editor.org/rfc/rfc7643#section-4.1.2" class="relref">Section 4.1.2</a> of [<a href="#RFC7643" class="xref">RFC7643</a>]</span>) as claim types.<a href="#section-2.2.3.1-2" class="pilcrow">¶</a></p>
<p id="section-2.2.3.1-3">
Authorization servers <span class="bcp14">SHOULD</span> encode the corresponding claim values according to the guidance defined in <span>[<a href="#RFC7643" class="xref">RFC7643</a>]</span>. In particular, a non-normative example of a "groups" attribute can be found in <span><a href="https://www.rfc-editor.org/rfc/rfc7643#section-8.2" class="relref">Section 8.2</a> of [<a href="#RFC7643" class="xref">RFC7643</a>]</span>. No specific vocabulary is provided for "roles" and "entitlements".<a href="#section-2.2.3.1-3" class="pilcrow">¶</a></p>
<p id="section-2.2.3.1-4">
                            <a href="#IANAClaimsContent" class="xref">Section 7.2.1</a> of this document provides entries for registering "groups", "roles", and "entitlements" attributes from 
                            <span>[<a href="#RFC7643" class="xref">RFC7643</a>]</span> as claim types to be used in this profile.<a href="#section-2.2.3.1-4" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
</section>
</div>
</section>
</div>
<div id="JWTATLRequest">
<section id="section-3">
      <h2 id="name-requesting-a-jwt-access-tok">
<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-requesting-a-jwt-access-tok" class="section-name selfRef">Requesting a JWT Access Token</a>
      </h2>
<p id="section-3-1">
 An authorization server can issue a JWT access token in response to any authorization grant defined by 
                <span>[<a href="#RFC6749" class="xref">RFC6749</a>]</span> and subsequent extensions meant to result in an access token.<a href="#section-3-1" class="pilcrow">¶</a></p>
<p id="section-3-2">If the request includes a "resource" parameter (as defined in 
                <span>[<a href="#RFC8707" class="xref">RFC8707</a>]</span>), the resulting JWT access token "aud" claim <span class="bcp14">SHOULD</span> have the same value as the "resource" parameter in the request.<a href="#section-3-2" class="pilcrow">¶</a></p>
<p id="section-3-3">Example request below:<a href="#section-3-3" class="pilcrow">¶</a></p>
<span id="name-authorization-request-with-"></span><div id="authz-endpoint-example-code">
<figure id="figure-1">
        <div id="section-3-4.1">
<pre class="sourcecode">
GET /as/authorization.oauth2?response_type=code
        &amp;client_id=s6BhdRkqt3
        &amp;state=xyz
        &amp;scope=openid%20profile%20reademail
        &amp;redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
        &amp;resource=https%3A%2F%2Frs.example.com%2F HTTP/1.1
     Host: authorization-server.example.com
</pre>
</div>
<figcaption><a href="#figure-1" class="selfRef">Figure 1</a>:
<a href="#name-authorization-request-with-" class="selfRef">Authorization Request with Resource and Scope Parameters</a>
        </figcaption></figure>
</div>
<p id="section-3-5">
 Once redeemed, the code obtained from the request above will result in a JWT access token in the form shown below:<a href="#section-3-5" class="pilcrow">¶</a></p>
<span id="name-the-header-and-jwt-claims-s"></span><div id="jwt-at-example-code">
<figure id="figure-2">
        <div id="section-3-6.1">
<pre class="lang-json sourcecode">
Header:

   {"typ":"at+JWT","alg":"RS256","kid":"RjEwOwOA"}

Claims:

   {
     "iss": "https://authorization-server.example.com/",
     "sub": "5ba552d67",
     "aud":   "https://rs.example.com/",
     "exp": 1639528912,
     "iat": 1618354090,
     "jti" : "dbe39bf3a3ba4238a513f51d6e1691c4",
     "client_id": "s6BhdRkqt3",
     "scope": "openid profile reademail"
   }
</pre>
</div>
<figcaption><a href="#figure-2" class="selfRef">Figure 2</a>:
<a href="#name-the-header-and-jwt-claims-s" class="selfRef">The Header and JWT Claims Set of a JWT Access Token</a>
        </figcaption></figure>
</div>
<p id="section-3-7">
 The authorization server <span class="bcp14">MUST NOT</span> issue a JWT access token if the authorization granted by the token would be ambiguous.  
 See 
                <a href="#SecurityConsiderations" class="xref">Section 5</a> for more details about common cases that might lead to ambiguity and strategies an authorization server can enact to prevent them.<a href="#section-3-7" class="pilcrow">¶</a></p>
<p id="section-3-8">
 If the request does not include a "resource" parameter, the authorization server <span class="bcp14">MUST</span> use a default resource indicator in the "aud" claim. If a "scope" parameter is present in the request, the authorization server <span class="bcp14">SHOULD</span> use it to infer the value of the default resource indicator to be used in the "aud" claim. The mechanism through which scopes are associated with default resource indicator values is outside the scope of this specification. If the values in the "scope" parameter refer to different default resource indicator values, the authorization server <span class="bcp14">SHOULD</span> reject the request with "invalid_scope" as described in <span><a href="https://www.rfc-editor.org/rfc/rfc6749#section-4.1.2.1" class="relref">Section 4.1.2.1</a> of [<a href="#RFC6749" class="xref">RFC6749</a>]</span>.<a href="#section-3-8" class="pilcrow">¶</a></p>
</section>
</div>
<div id="JWTATLValidate">
<section id="section-4">
      <h2 id="name-validating-jwt-access-token">
<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-validating-jwt-access-token" class="section-name selfRef">Validating JWT Access Tokens</a>
      </h2>
<p id="section-4-1">
 For the purpose of facilitating validation data retrieval, it is <span class="bcp14">RECOMMENDED</span> here that authorization servers sign JWT access tokens with an asymmetric algorithm.<a href="#section-4-1" class="pilcrow">¶</a></p>
<p id="section-4-2">
 Authorization servers <span class="bcp14">SHOULD</span> use 
                <span><a href="#RFC8414" class="xref">OAuth 2.0 Authorization Server Metadata</a> [<a href="#RFC8414" class="xref">RFC8414</a>]</span> to advertise to resource servers their signing keys via "jwks_uri" and what "iss" claim value to expect 
                via the "issuer" metadata value. Alternatively, authorization servers implementing OpenID Connect <span class="bcp14">MAY</span> use the <span><a href="#OpenID.Discovery" class="xref">OpenID Connect discovery</a> [<a href="#OpenID.Discovery" class="xref">OpenID.Discovery</a>]</span> document for the same purpose. If an authorization server supports both OAuth 2.0 Authorization Server Metadata and OpenID Connect discovery, the values provided <span class="bcp14">MUST</span> be consistent across the two publication methods.<a href="#section-4-2" class="pilcrow">¶</a></p>
<p id="section-4-3">
 An authorization server <span class="bcp14">MAY</span> elect to use different keys to sign OpenID Connect ID Tokens and JWT access tokens. This specification does not provide a mechanism for identifying a specific key as the one used to sign JWT access tokens. An authorization server can sign JWT access tokens with any of the keys advertised via authorization server (AS) metadata or OpenID Connect discovery. See 
                <a href="#SecurityConsiderations" class="xref">Section 5</a> for further guidance on security implications.<a href="#section-4-3" class="pilcrow">¶</a></p>
<p id="section-4-4">
 Resource servers receiving a JWT access token <span class="bcp14">MUST</span> validate it in the following manner.<a href="#section-4-4" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-4-5.1"> 
The resource server <span class="bcp14">MUST</span> verify that the "typ" header value is "at+jwt" or "application/at+jwt" and reject tokens carrying any other value.<a href="#section-4-5.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-4-5.2">
If the JWT access token is encrypted, decrypt it using the keys and algorithms that the resource server specified during registration. If encryption was negotiated with the authorization server at registration time and the incoming JWT access token is not encrypted, the resource server <span class="bcp14">SHOULD</span> reject it.<a href="#section-4-5.2" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-4-5.3">
The issuer identifier for the authorization server (which is typically obtained during discovery) <span class="bcp14">MUST</span> exactly match the value of the "iss" claim.<a href="#section-4-5.3" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-4-5.4">
The resource server <span class="bcp14">MUST</span> validate that the "aud" claim contains a resource indicator value corresponding to an identifier the resource server expects for itself. The JWT access token <span class="bcp14">MUST</span> be rejected if "aud" does not contain a resource indicator of the current resource server as a valid audience.<a href="#section-4-5.4" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-4-5.5">
The resource server <span class="bcp14">MUST</span> validate the signature of all incoming JWT access tokens according to 
                        
                        
                        
                        <span>[<a href="#RFC7515" class="xref">RFC7515</a>]</span> using the algorithm specified in the JWT "alg" Header Parameter. The resource server <span class="bcp14">MUST</span> reject any JWT in which the value of "alg" is "none". The resource server <span class="bcp14">MUST</span> use the keys provided by the authorization server.<a href="#section-4-5.5" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-4-5.6">
The current time <span class="bcp14">MUST</span> be before the time represented by the "exp" claim. Implementers <span class="bcp14">MAY</span> provide for some small leeway, usually no more than a few minutes, to account for clock skew.<a href="#section-4-5.6" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-4-6">
            The resource server <span class="bcp14">MUST</span> handle errors as described in <span><a href="https://www.rfc-editor.org/rfc/rfc6750#section-3.1" class="relref">Section 3.1</a> of [<a href="#RFC6750" class="xref">RFC6750</a>]</span>. In particular, in case of any failure in the validation checks listed above, the authorization server response <span class="bcp14">MUST</span> include the error code "invalid_token".

                Please note that this requirement does not prevent JWT access tokens from using authentication schemes other than "Bearer".<a href="#section-4-6" class="pilcrow">¶</a></p>
<p id="section-4-7"> 
If the JWT access token includes authorization claims as described in 
                <a href="#AuthorizationClaims" class="xref">Section 2.2.3</a>, the resource server <span class="bcp14">SHOULD</span> use them in combination with any other contextual information available to determine whether the current call should be authorized or rejected. Details about how a resource server performs those checks is beyond the scope of this profile specification.<a href="#section-4-7" class="pilcrow">¶</a></p>
</section>
</div>
<div id="SecurityConsiderations">
<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>
<p id="section-5-1">
 The JWT access token data layout described here is very similar to that of the id_token as defined by 
                <span>[<a href="#OpenID.Core" class="xref">OpenID.Core</a>]</span>. The explicit typing required in this profile, in line with the recommendations in 
                <span>[<a href="#RFC8725" class="xref">RFC8725</a>]</span>, helps the resource server to distinguish between JWT access tokens and OpenID Connect ID Tokens.<a href="#section-5-1" class="pilcrow">¶</a></p>
<p id="section-5-2">
 Authorization servers should prevent scenarios where clients can affect the value of the "sub" claim in ways that could confuse resource servers. 
            For example, if the authorization server elects to use the client_id as the "sub" value for access tokens issued using the client credentials grant, the authorization server should prevent clients from registering an arbitrary client_id value, as this would allow malicious clients to select the sub of a high-privilege resource owner and confuse any authorization logic on the resource server relying on the "sub" value.       
 For more details, please refer to <span><a href="https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-18#section-4.14" class="relref">Section 4.14</a> of [<a href="#I-D.ietf-oauth-security-topics" class="xref">OAuth2.Security.BestPractices</a>]</span>.<a href="#section-5-2" class="pilcrow">¶</a></p>
<p id="section-5-3">
To prevent cross-JWT confusion, authorization servers <span class="bcp14">MUST</span> use a distinct identifier as an "aud" claim value to uniquely identify access tokens issued by the same issuer for distinct resources. For more details on cross-JWT confusion, please refer to <span><a href="https://www.rfc-editor.org/rfc/rfc8725#section-2.8" class="relref">Section 2.8</a> of [<a href="#RFC8725" class="xref">RFC8725</a>]</span>.<a href="#section-5-3" class="pilcrow">¶</a></p>
<p id="section-5-4">
 Authorization servers should use particular care when handling requests that might lead to ambiguous authorization grants. For example, if a request includes multiple resource indicators, the authorization server should ensure that each scope string included in the resulting JWT access token, if any, can be unambiguously correlated to a specific resource among the ones listed in the "aud" claim. The details on how to recognize and mitigate this and other ambiguous situations is highly scenario dependent and hence is out of scope for this profile.<a href="#section-5-4" class="pilcrow">¶</a></p>
<p id="section-5-5">
            Authorization servers cannot rely on the use of different keys for signing OpenID Connect ID Tokens and JWT tokens as a method to safeguard against the consequences of leaking specific keys. Given that resource servers have no way of knowing what key should be used to validate JWT access tokens in particular, they have to accept signatures performed with any of the keys published in AS metadata or OpenID Connect discovery; consequently, an attacker just needs to compromise any key among the ones published to be able to generate and sign JWTs that will be accepted as valid by the resource server.<a href="#section-5-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="PrivacyConsiderations">
<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">
  As JWT access tokens carry information by value, it now becomes possible for clients and potentially even end users to directly peek inside the token claims collection of unencrypted tokens.<a href="#section-6-1" class="pilcrow">¶</a></p>
<p id="section-6-2">
 The client <span class="bcp14">MUST NOT</span> inspect the content of the access token: the authorization server and the resource server might decide to change the token format at any time (for example, by switching from this profile to opaque tokens); hence, any logic in the client relying on the ability to read the access token content would break without recourse. 
            The OAuth 2.0 framework assumes that access tokens are treated as opaque by clients. 
 Administrators of authorization servers should also take into account that the content of an access token is visible to the client. 
            Whenever client access to the access token content presents privacy issues for a given scenario, the authorization server needs to take explicit steps to prevent them.<a href="#section-6-2" class="pilcrow">¶</a></p>
<p id="section-6-3">
 In scenarios in which JWT access tokens are accessible to the end user, it should be evaluated whether the information can be accessed without privacy violations (for example, if an end user would simply access his or her own personal information) or if steps must be taken to enforce confidentiality.<a href="#section-6-3" class="pilcrow">¶</a></p>
<p id="section-6-4">
            Possible measures to prevent leakage of information to clients and end users include: encrypting the access token, encrypting the sensitive claims, omitting the sensitive claims or not using this profile, and falling back on opaque access tokens.<a href="#section-6-4" class="pilcrow">¶</a></p>
<p id="section-6-5">
 In every scenario, the content of the JWT access token will eventually be accessible to the resource server. It's important to evaluate whether 
 the resource server gained the proper entitlement to have access to any content received in the form of claims, for example, through user consent 
 in some form, policies and agreements with the organization running the authorization servers, and so on. 
            For example, a user might not wish to consent to granting given resource server information about any of the non-mandatory claims enumerated in <a href="#JWTATLayout" class="xref">Section 2</a> (and its subsections).<a href="#section-6-5" class="pilcrow">¶</a></p>
<p id="section-6-6">
             This profile mandates the presence of the "sub" claim in every JWT access token, making it possible for resource servers to rely on that information for correlating incoming requests with data stored locally for the authenticated principal. 
             Although the ability to correlate requests might be required by design in many scenarios, there are scenarios where the authorization server might want to prevent correlation. The "sub" claim should be populated by the authorization servers according to a privacy impact assessment.
             For instance, if a solution requires preventing tracking of principal activities across multiple resource servers, the authorization server should ensure that JWT access tokens meant for different resource servers have distinct "sub" values that cannot be correlated in the event of resource server collusion.  
             Similarly, if a solution requires preventing a resource server from correlating the principal's activity within the resource itself, the authorization server should assign different "sub" values for every JWT access token issued. 
             In turn, the client should obtain a new JWT access token for every call to the resource server to ensure that the resource server receives different "sub" and "jti" values at every call, thus preventing correlation between distinct requests.<a href="#section-6-6" class="pilcrow">¶</a></p>
</section>
</div>
<div id="IANA">
<section id="section-7">
      <h2 id="name-iana-considerations">
<a href="#section-7" class="section-number selfRef">7. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a>
      </h2>
<div id="IANAMediaTypes">
<section id="section-7.1">
        <h3 id="name-media-type-registration">
<a href="#section-7.1" class="section-number selfRef">7.1. </a><a href="#name-media-type-registration" class="section-name selfRef">Media Type Registration</a>
        </h3>
<div id="IANAMediaTypesContent">
<section id="section-7.1.1">
          <h4 id="name-registry-content">
<a href="#section-7.1.1" class="section-number selfRef">7.1.1. </a><a href="#name-registry-content" class="section-name selfRef">Registry Content</a>
          </h4>
<p id="section-7.1.1-1">
     This section registers "application/at+jwt", a new media type <span>[<a href="#RFC2046" class="xref">RFC2046</a>]</span> in the "Media Types" registry <span>[<a href="#IANA.MediaTypes" class="xref">IANA.MediaTypes</a>]</span> in the
   manner described in <span>[<a href="#RFC6838" class="xref">RFC6838</a>]</span>. It can be used to indicate that the
   content is an access token encoded in JWT format.<a href="#section-7.1.1-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-7.1.1-2">
            <dt id="section-7.1.1-2.1">Type name:</dt>
            <dd style="margin-left: 1.5em" id="section-7.1.1-2.2"> Application<a href="#section-7.1.1-2.2" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-7.1.1-2.3">Subtype name:</dt>
            <dd style="margin-left: 1.5em" id="section-7.1.1-2.4">at+jwt<a href="#section-7.1.1-2.4" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-7.1.1-2.5">Required parameters:</dt>
            <dd style="margin-left: 1.5em" id="section-7.1.1-2.6">N/A<a href="#section-7.1.1-2.6" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-7.1.1-2.7">Optional parameters:</dt>
            <dd style="margin-left: 1.5em" id="section-7.1.1-2.8">N/A<a href="#section-7.1.1-2.8" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-7.1.1-2.9">Encoding considerations:</dt>
            <dd style="margin-left: 1.5em" id="section-7.1.1-2.10"> Binary; JWT values are
      encoded as a series of base64url-encoded values (with trailing '='
      characters removed), some of which may be the empty string,
      separated by period ('.') characters.<a href="#section-7.1.1-2.10" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-7.1.1-2.11">Security considerations:</dt>
            <dd style="margin-left: 1.5em" id="section-7.1.1-2.12"> See the Security Considerations section of RFC 9068.<a href="#section-7.1.1-2.12" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-7.1.1-2.13">Interoperability considerations:</dt>
            <dd style="margin-left: 1.5em" id="section-7.1.1-2.14">N/A<a href="#section-7.1.1-2.14" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-7.1.1-2.15">Published specification:</dt>
            <dd style="margin-left: 1.5em" id="section-7.1.1-2.16">RFC 9068<a href="#section-7.1.1-2.16" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-7.1.1-2.17">Applications that use this media type:</dt>
            <dd style="margin-left: 1.5em" id="section-7.1.1-2.18"> Applications that access resource servers using OAuth 2.0 access tokens encoded in JWT format<a href="#section-7.1.1-2.18" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-7.1.1-2.19">Fragment identifier considerations:</dt>
            <dd style="margin-left: 1.5em" id="section-7.1.1-2.20">N/A<a href="#section-7.1.1-2.20" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-7.1.1-2.21">Additional information:</dt>
            <dd style="margin-left: 1.5em" id="section-7.1.1-2.22">
              <p id="section-7.1.1-2.22.1"><br></p>
<span class="break"></span><dl class="dlCompact dlParallel" id="section-7.1.1-2.22.2">
                <dt id="section-7.1.1-2.22.2.1">Magic number(s):</dt>
                <dd style="margin-left: 1.5em" id="section-7.1.1-2.22.2.2">N/A<a href="#section-7.1.1-2.22.2.2" class="pilcrow">¶</a>
</dd>
                <dd class="break"></dd>
<dt id="section-7.1.1-2.22.2.3">File extension(s):</dt>
                <dd style="margin-left: 1.5em" id="section-7.1.1-2.22.2.4">N/A<a href="#section-7.1.1-2.22.2.4" class="pilcrow">¶</a>
</dd>
                <dd class="break"></dd>
<dt id="section-7.1.1-2.22.2.5">Macintosh file type code(s):</dt>
                <dd style="margin-left: 1.5em" id="section-7.1.1-2.22.2.6">N/A<a href="#section-7.1.1-2.22.2.6" class="pilcrow">¶</a>
</dd>
              <dd class="break"></dd>
</dl>
</dd>
            <dd class="break"></dd>
<dt id="section-7.1.1-2.23">Person &amp; email address to contact for further information:</dt>
            <dd style="margin-left: 1.5em" id="section-7.1.1-2.24">
              <p id="section-7.1.1-2.24.1"><br>Vittorio Bertocci &lt;vittorio@auth0.com&gt;<a href="#section-7.1.1-2.24.1" class="pilcrow">¶</a></p>
</dd>
            <dd class="break"></dd>
<dt id="section-7.1.1-2.25">Intended usage:</dt>
            <dd style="margin-left: 1.5em" id="section-7.1.1-2.26"> COMMON<a href="#section-7.1.1-2.26" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-7.1.1-2.27">Restrictions on usage:</dt>
            <dd style="margin-left: 1.5em" id="section-7.1.1-2.28"> None<a href="#section-7.1.1-2.28" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-7.1.1-2.29">Author:</dt>
            <dd style="margin-left: 1.5em" id="section-7.1.1-2.30">Vittorio Bertocci &lt;vittorio@auth0.com&gt;<a href="#section-7.1.1-2.30" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-7.1.1-2.31">Change controller:</dt>
            <dd style="margin-left: 1.5em" id="section-7.1.1-2.32">IETF<a href="#section-7.1.1-2.32" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-7.1.1-2.33">Provisional registration?</dt>
            <dd style="margin-left: 1.5em" id="section-7.1.1-2.34">No<a href="#section-7.1.1-2.34" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
</dl>
</section>
</div>
</section>
</div>
<div id="IANAClaimTypes">
<section id="section-7.2">
        <h3 id="name-claims-registration">
<a href="#section-7.2" class="section-number selfRef">7.2. </a><a href="#name-claims-registration" class="section-name selfRef">Claims Registration</a>
        </h3>
<p id="section-7.2-1">
                        <a href="#NDAuthorizationClaims" class="xref">Section 2.2.3.1</a> of this specification refers to the attributes "roles", "groups", "entitlements" defined in 
                        <span>[<a href="#RFC7643" class="xref">RFC7643</a>]</span> to express authorization information in JWT access tokens.
 This section registers those attributes as claims in the "JSON Web Token (JWT)" IANA registry introduced in 
                        <span>[<a href="#RFC7519" class="xref">RFC7519</a>]</span>.<a href="#section-7.2-1" class="pilcrow">¶</a></p>
<div id="IANAClaimsContent">
<section id="section-7.2.1">
          <h4 id="name-registry-content-2">
<a href="#section-7.2.1" class="section-number selfRef">7.2.1. </a><a href="#name-registry-content-2" class="section-name selfRef">Registry Content</a>
          </h4>
<div id="IANARoles">
<section id="section-7.2.1.1">
            <h5 id="name-roles">
<a href="#section-7.2.1.1" class="section-number selfRef">7.2.1.1. </a><a href="#name-roles" class="section-name selfRef">Roles</a>
            </h5>
<span class="break"></span><dl class="dlCompact dlParallel" id="section-7.2.1.1-1">
              <dt id="section-7.2.1.1-1.1">Claim Name:</dt>
              <dd style="margin-left: 1.5em" id="section-7.2.1.1-1.2">roles<a href="#section-7.2.1.1-1.2" class="pilcrow">¶</a>
</dd>
              <dd class="break"></dd>
<dt id="section-7.2.1.1-1.3">Claim Description:</dt>
              <dd style="margin-left: 1.5em" id="section-7.2.1.1-1.4"> Roles<a href="#section-7.2.1.1-1.4" class="pilcrow">¶</a>
</dd>
              <dd class="break"></dd>
<dt id="section-7.2.1.1-1.5">Change Controller:</dt>
              <dd style="margin-left: 1.5em" id="section-7.2.1.1-1.6">IETF<a href="#section-7.2.1.1-1.6" class="pilcrow">¶</a>
</dd>
              <dd class="break"></dd>
<dt id="section-7.2.1.1-1.7">Specification Document(s):</dt>
              <dd style="margin-left: 1.5em" id="section-7.2.1.1-1.8">
                <span><a href="https://www.rfc-editor.org/rfc/rfc7643#section-4.1.2" class="relref">Section 4.1.2</a> of [<a href="#RFC7643" class="xref">RFC7643</a>]</span> and <a href="#NDAuthorizationClaims" class="xref">Section 2.2.3.1</a> of RFC 9068<a href="#section-7.2.1.1-1.8" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
</dl>
</section>
</div>
<div id="IANAGroups">
<section id="section-7.2.1.2">
            <h5 id="name-groups">
<a href="#section-7.2.1.2" class="section-number selfRef">7.2.1.2. </a><a href="#name-groups" class="section-name selfRef">Groups</a>
            </h5>
<span class="break"></span><dl class="dlCompact dlParallel" id="section-7.2.1.2-1">
              <dt id="section-7.2.1.2-1.1">Claim Name:</dt>
              <dd style="margin-left: 1.5em" id="section-7.2.1.2-1.2"> groups<a href="#section-7.2.1.2-1.2" class="pilcrow">¶</a>
</dd>
              <dd class="break"></dd>
<dt id="section-7.2.1.2-1.3">Claim Description:</dt>
              <dd style="margin-left: 1.5em" id="section-7.2.1.2-1.4">Groups<a href="#section-7.2.1.2-1.4" class="pilcrow">¶</a>
</dd>
              <dd class="break"></dd>
<dt id="section-7.2.1.2-1.5">Change Controller:</dt>
              <dd style="margin-left: 1.5em" id="section-7.2.1.2-1.6">IETF<a href="#section-7.2.1.2-1.6" class="pilcrow">¶</a>
</dd>
              <dd class="break"></dd>
<dt id="section-7.2.1.2-1.7">Specification Document(s):</dt>
              <dd style="margin-left: 1.5em" id="section-7.2.1.2-1.8">
                <span><a href="https://www.rfc-editor.org/rfc/rfc7643#section-4.1.2" class="relref">Section 4.1.2</a> of [<a href="#RFC7643" class="xref">RFC7643</a>]</span> and <a href="#NDAuthorizationClaims" class="xref">Section 2.2.3.1</a> of RFC 9068<a href="#section-7.2.1.2-1.8" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
</dl>
</section>
</div>
<div id="IANAEntitlements">
<section id="section-7.2.1.3">
            <h5 id="name-entitlements">
<a href="#section-7.2.1.3" class="section-number selfRef">7.2.1.3. </a><a href="#name-entitlements" class="section-name selfRef">Entitlements</a>
            </h5>
<span class="break"></span><dl class="dlCompact dlParallel" id="section-7.2.1.3-1">
              <dt id="section-7.2.1.3-1.1">Claim Name:</dt>
              <dd style="margin-left: 1.5em" id="section-7.2.1.3-1.2"> entitlements<a href="#section-7.2.1.3-1.2" class="pilcrow">¶</a>
</dd>
              <dd class="break"></dd>
<dt id="section-7.2.1.3-1.3">Claim Description:</dt>
              <dd style="margin-left: 1.5em" id="section-7.2.1.3-1.4"> Entitlements<a href="#section-7.2.1.3-1.4" class="pilcrow">¶</a>
</dd>
              <dd class="break"></dd>
<dt id="section-7.2.1.3-1.5">Change Controller:</dt>
              <dd style="margin-left: 1.5em" id="section-7.2.1.3-1.6">IETF<a href="#section-7.2.1.3-1.6" class="pilcrow">¶</a>
</dd>
              <dd class="break"></dd>
<dt id="section-7.2.1.3-1.7">Specification Document(s):</dt>
              <dd style="margin-left: 1.5em" id="section-7.2.1.3-1.8">
                <span><a href="https://www.rfc-editor.org/rfc/rfc7643#section-4.1.2" class="relref">Section 4.1.2</a> of [<a href="#RFC7643" class="xref">RFC7643</a>]</span> and <a href="#NDAuthorizationClaims" class="xref">Section 2.2.3.1</a> of RFC 9068<a href="#section-7.2.1.3-1.8" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
</dl>
</section>
</div>
</section>
</div>
</section>
</div>
</section>
</div>
<section id="section-8">
      <h2 id="name-references">
<a href="#section-8" class="section-number selfRef">8. </a><a href="#name-references" class="section-name selfRef">References</a>
      </h2>
<section id="section-8.1">
        <h3 id="name-normative-references">
<a href="#section-8.1" class="section-number selfRef">8.1. </a><a href="#name-normative-references" class="section-name selfRef">Normative References</a>
        </h3>
<dl class="references">
<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.</span>, <span class="refAuthor">de Medeiros, B.</span>, and <span class="refAuthor">C. Mortimore</span>, <span class="refTitle">"OpenID Connect Core 1.0 incorporating errata set 1"</span>, <time datetime="2014-11" class="refDate">November 2014</time>, <span>&lt;<a href="https://openid.net/specs/openid-connect-core-1_0.html">https://openid.net/specs/openid-connect-core-1_0.html</a>&gt;</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.</span>, and <span class="refAuthor">E. Jay</span>, <span class="refTitle">"OpenID Connect Discovery 1.0 incorporating errata set 1"</span>, <time datetime="2014-11" class="refDate">November 2014</time>, <span>&lt;<a href="https://openid.net/specs/openid-connect-discovery-1_0.html">https://openid.net/specs/openid-connect-discovery-1_0.html</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC2046">[RFC2046]</dt>
        <dd>
<span class="refAuthor">Freed, N.</span> and <span class="refAuthor">N. Borenstein</span>, <span class="refTitle">"Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types"</span>, <span class="seriesInfo">RFC 2046</span>, <span class="seriesInfo">DOI 10.17487/RFC2046</span>, <time datetime="1996-11" class="refDate">November 1996</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2046">https://www.rfc-editor.org/info/rfc2046</a>&gt;</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>&lt;<a href="https://www.rfc-editor.org/info/rfc2119">https://www.rfc-editor.org/info/rfc2119</a>&gt;</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>&lt;<a href="https://www.rfc-editor.org/info/rfc6749">https://www.rfc-editor.org/info/rfc6749</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6838">[RFC6838]</dt>
        <dd>
<span class="refAuthor">Freed, N.</span>, <span class="refAuthor">Klensin, J.</span>, and <span class="refAuthor">T. Hansen</span>, <span class="refTitle">"Media Type Specifications and Registration Procedures"</span>, <span class="seriesInfo">BCP 13</span>, <span class="seriesInfo">RFC 6838</span>, <span class="seriesInfo">DOI 10.17487/RFC6838</span>, <time datetime="2013-01" class="refDate">January 2013</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6838">https://www.rfc-editor.org/info/rfc6838</a>&gt;</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>&lt;<a href="https://www.rfc-editor.org/info/rfc7515">https://www.rfc-editor.org/info/rfc7515</a>&gt;</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>&lt;<a href="https://www.rfc-editor.org/info/rfc7518">https://www.rfc-editor.org/info/rfc7518</a>&gt;</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>&lt;<a href="https://www.rfc-editor.org/info/rfc7519">https://www.rfc-editor.org/info/rfc7519</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7643">[RFC7643]</dt>
        <dd>
<span class="refAuthor">Hunt, P., Ed.</span>, <span class="refAuthor">Grizzle, K.</span>, <span class="refAuthor">Wahlstroem, E.</span>, and <span class="refAuthor">C. Mortimore</span>, <span class="refTitle">"System for Cross-domain Identity Management: Core Schema"</span>, <span class="seriesInfo">RFC 7643</span>, <span class="seriesInfo">DOI 10.17487/RFC7643</span>, <time datetime="2015-09" class="refDate">September 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7643">https://www.rfc-editor.org/info/rfc7643</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8174">[RFC8174]</dt>
        <dd>
<span class="refAuthor">Leiba, B.</span>, <span class="refTitle">"Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 8174</span>, <span class="seriesInfo">DOI 10.17487/RFC8174</span>, <time datetime="2017-05" class="refDate">May 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8174">https://www.rfc-editor.org/info/rfc8174</a>&gt;</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>&lt;<a href="https://www.rfc-editor.org/info/rfc8414">https://www.rfc-editor.org/info/rfc8414</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8693">[RFC8693]</dt>
        <dd>
<span class="refAuthor">Jones, M.</span>, <span class="refAuthor">Nadalin, A.</span>, <span class="refAuthor">Campbell, B., Ed.</span>, <span class="refAuthor">Bradley, J.</span>, and <span class="refAuthor">C. Mortimore</span>, <span class="refTitle">"OAuth 2.0 Token Exchange"</span>, <span class="seriesInfo">RFC 8693</span>, <span class="seriesInfo">DOI 10.17487/RFC8693</span>, <time datetime="2020-01" class="refDate">January 2020</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8693">https://www.rfc-editor.org/info/rfc8693</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8707">[RFC8707]</dt>
        <dd>
<span class="refAuthor">Campbell, B.</span>, <span class="refAuthor">Bradley, J.</span>, and <span class="refAuthor">H. Tschofenig</span>, <span class="refTitle">"Resource Indicators for OAuth 2.0"</span>, <span class="seriesInfo">RFC 8707</span>, <span class="seriesInfo">DOI 10.17487/RFC8707</span>, <time datetime="2020-02" class="refDate">February 2020</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8707">https://www.rfc-editor.org/info/rfc8707</a>&gt;</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>&lt;<a href="https://www.rfc-editor.org/info/rfc8725">https://www.rfc-editor.org/info/rfc8725</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
<section id="section-8.2">
        <h3 id="name-informative-references">
<a href="#section-8.2" class="section-number selfRef">8.2. </a><a href="#name-informative-references" class="section-name selfRef">Informative References</a>
        </h3>
<dl class="references">
<dt id="IANA.MediaTypes">[IANA.MediaTypes]</dt>
        <dd>
<span class="refAuthor">IANA</span>, <span class="refTitle">"Media Types"</span>, <span>&lt;<a href="https://www.iana.org/assignments/media-types/">https://www.iana.org/assignments/media-types/</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.ietf-oauth-security-topics">[OAuth2.Security.BestPractices]</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">"OAuth 2.0 Security Best Current Practice"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-oauth-security-topics-18</span>, <time datetime="2021-04-13" class="refDate">13 April 2021</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-18">https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-18</a>&gt;</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>&lt;<a href="https://www.rfc-editor.org/info/rfc6750">https://www.rfc-editor.org/info/rfc6750</a>&gt;</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>&lt;<a href="https://www.rfc-editor.org/info/rfc7523">https://www.rfc-editor.org/info/rfc7523</a>&gt;</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>&lt;<a href="https://www.rfc-editor.org/info/rfc7662">https://www.rfc-editor.org/info/rfc7662</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
</section>
<div id="Acknowledgements">
<section id="appendix-A">
      <h2 id="name-acknowledgements">
<a href="#name-acknowledgements" class="section-name selfRef">Acknowledgements</a>
      </h2>
<p id="appendix-A-1">
        The initial set of requirements informing this specification was extracted by numerous examples of access tokens issued in JWT format by production systems.
Thanks to <span class="contact-name">Dominick Baier</span> (IdentityServer), <span class="contact-name">Brian Campbell</span> (Ping Identity), <span class="contact-name">Daniel Dobalian</span> (Microsoft), and <span class="contact-name">Karl Guinness</span> (Okta) for providing sample tokens issued by their products and services. 
 <span class="contact-name">Brian Campbell</span> and <span class="contact-name">Filip Skokan</span> provided early feedback that shaped the direction of the specification.
 This profile was discussed at length during the OAuth Security Workshop 2019, with several individuals contributing ideas and feedback. The author would like to acknowledge the contributions of:<a href="#appendix-A-1" class="pilcrow">¶</a></p>
<p id="appendix-A-2">
        <span class="contact-name">John Bradley</span>,
 <span class="contact-name">Brian Campbell</span>,
 <span class="contact-name">Vladimir Dzhuvinov</span>,
        <span class="contact-name">Torsten Lodderstedt</span>,
        <span class="contact-name">Nat Sakimura</span>,
 <span class="contact-name">Hannes Tschofenig</span>,         
        and
        everyone who actively participated in the unconference discussions.<a href="#appendix-A-2" class="pilcrow">¶</a></p>
<p id="appendix-A-3">
 The following individuals contributed useful feedback and insights on the drafts, both at the IETF OAuth 2.0 WG mailing list and during the 28th Internet Identity Workshop (IIW 28):<a href="#appendix-A-3" class="pilcrow">¶</a></p>
<p id="appendix-A-4">
        <span class="contact-name">Dale Olds</span>,
 <span class="contact-name">George Fletcher</span>,
 <span class="contact-name">David Waite</span>,
        <span class="contact-name">Michael Engan</span>,
        <span class="contact-name">Mike Jones</span>,
        <span class="contact-name">Hans Zandbelt</span>,
        <span class="contact-name">Vladimir Dzhuvinov</span>,
        <span class="contact-name">Martin Schanzenbach</span>,
 <span class="contact-name">Aaron Parecki</span>,
 <span class="contact-name">Annabelle Richard Backman</span>,
        <span class="contact-name">Dick Hardt</span>,
        <span class="contact-name">Denis Pinkas</span>,
        <span class="contact-name">Benjamin Kaduk</span>,
        <span class="contact-name">Dominick Baier</span>,
        <span class="contact-name">Andrii Deinega</span>,
        <span class="contact-name">Mike Jones</span>,  
        and
        everyone who actively participated in the IIW 28 unconference discussions and the IETF OAuth 2.0 WG mailing list discussions.
        Thanks to <span class="contact-name">Roman Danyliw</span> for the AD review; <span class="contact-name">Joseph Salowey</span> and <span class="contact-name">Roni Even</span> for the SECDIR and GENART reviews; and <span class="contact-name">Francesca Palomini</span>, <span class="contact-name">Lars Eggert</span>, <span class="contact-name">Murray Kucherawy</span>, <span class="contact-name">Roberto Polli</span>, <span class="contact-name">Martin Duke</span>, <span class="contact-name">Benjamin Kaduk</span> for the IESG reviews.<a href="#appendix-A-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="authors-addresses">
<section id="appendix-B">
      <h2 id="name-authors-address">
<a href="#name-authors-address" class="section-name selfRef">Author's Address</a>
      </h2>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Vittorio Bertocci</span></div>
<div dir="auto" class="left"><span class="org">Auth0</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:vittorio@auth0.com" class="email">vittorio@auth0.com</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>