<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Helvetica;
panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:"Segoe UI Emoji";
panose-1:2 11 5 2 4 2 4 2 2 3;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.apple-tab-span
{mso-style-name:apple-tab-span;}
span.apple-converted-space
{mso-style-name:apple-converted-space;}
span.E-MailFormatvorlage21
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:70.85pt 70.85pt 2.0cm 70.85pt;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:356857132;
mso-list-template-ids:593384430;}
@list l0:level1
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:36.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level2
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:72.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:108.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:144.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level5
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:180.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:216.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:252.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level8
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:288.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:324.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1
{mso-list-id:612173038;
mso-list-template-ids:2043334582;}
@list l1:level1
{mso-level-start-at:2;
mso-level-number-format:alpha-upper;
mso-level-tab-stop:36.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1:level2
{mso-level-number-format:alpha-upper;
mso-level-tab-stop:72.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1:level3
{mso-level-number-format:alpha-upper;
mso-level-tab-stop:108.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1:level4
{mso-level-number-format:alpha-upper;
mso-level-tab-stop:144.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1:level5
{mso-level-number-format:alpha-upper;
mso-level-tab-stop:180.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1:level6
{mso-level-number-format:alpha-upper;
mso-level-tab-stop:216.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1:level7
{mso-level-number-format:alpha-upper;
mso-level-tab-stop:252.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1:level8
{mso-level-number-format:alpha-upper;
mso-level-tab-stop:288.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1:level9
{mso-level-number-format:alpha-upper;
mso-level-tab-stop:324.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l2
{mso-list-id:1050612470;
mso-list-template-ids:1527915282;}
@list l2:level1
{mso-level-number-format:alpha-upper;
mso-level-tab-stop:36.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l2:level2
{mso-level-number-format:alpha-upper;
mso-level-tab-stop:72.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l2:level3
{mso-level-number-format:alpha-upper;
mso-level-tab-stop:108.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l2:level4
{mso-level-number-format:alpha-upper;
mso-level-tab-stop:144.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l2:level5
{mso-level-number-format:alpha-upper;
mso-level-tab-stop:180.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l2:level6
{mso-level-number-format:alpha-upper;
mso-level-tab-stop:216.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l2:level7
{mso-level-number-format:alpha-upper;
mso-level-tab-stop:252.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l2:level8
{mso-level-number-format:alpha-upper;
mso-level-tab-stop:288.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l2:level9
{mso-level-number-format:alpha-upper;
mso-level-tab-stop:324.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l3
{mso-list-id:1887448924;
mso-list-template-ids:932633846;}
@list l3:level1
{mso-level-start-at:3;
mso-level-number-format:alpha-upper;
mso-level-tab-stop:36.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l3:level2
{mso-level-number-format:alpha-upper;
mso-level-tab-stop:72.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l3:level3
{mso-level-number-format:alpha-upper;
mso-level-tab-stop:108.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l3:level4
{mso-level-number-format:alpha-upper;
mso-level-tab-stop:144.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l3:level5
{mso-level-number-format:alpha-upper;
mso-level-tab-stop:180.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l3:level6
{mso-level-number-format:alpha-upper;
mso-level-tab-stop:216.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l3:level7
{mso-level-number-format:alpha-upper;
mso-level-tab-stop:252.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l3:level8
{mso-level-number-format:alpha-upper;
mso-level-tab-stop:288.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l3:level9
{mso-level-number-format:alpha-upper;
mso-level-tab-stop:324.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
ol
{margin-bottom:0cm;}
ul
{margin-bottom:0cm;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="DE" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Joseph,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">thanks a lot.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Your comments all are very helpful!<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">-Markus<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b>Von:</b> Joseph Heenan <joseph@authlete.com> <br>
<b>Gesendet:</b> Mittwoch, 18. Mai 2022 17:24<br>
<b>An:</b> [Quipsy] Markus Karg <karg@quipsy.de><br>
<b>Cc:</b> general@lists.openid.net<br>
<b>Betreff:</b> Re: [OpenID] Beginner's Question: Per-Function-Access-Rights<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Hi Markus<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Okay, I think I understand your position better now.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">So, yes, if you have to work with a range of existing IDPs then you’re quite limited, not entirely by the protocols but perhaps more by the capabilities of those iDPs and their implementations not having this kind of use case in mind.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">To answer your questions:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<div>
<p class="MsoNormal"><span class="apple-tab-span"> </span>• Is there something in OpenID / OAuth2 that fulfils per-function-grants, or do these standards only define RBAC?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
<div>
<p class="MsoNormal">Scopes (and other things you could use have the idp, directly or indirectly, embed into an access token) technically aren’t quite limited to RBAC but you definitely can’t expect to express a large number of fine grained permissions in any
of those ways and have wide interoperability with someone else’s iDP, and even if you could the UIs on the IDP for managing them may not work out well.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><span class="apple-tab-span"> </span>• Does OpenID / OAuth2 allow the separation of the authorization endpoint vendor from the token endpoint vendor? If yes, we would implement our own token endpoint producing our custom authorization
tokens in exchange for a standardized ID Token obtained from the IDP.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
<div>
<p class="MsoNormal">There’s no standard way for your own token endpoint to validate an authorization code issued by an iDP that’s not your own. (It would involve the token endpoint pretending, to your customer’s idp, to be your client, and at that point it’s
probably better to call it something other than “token endpoint” to avoid confusion.)<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">The general way you’d probably do this kind of model (which may or may not be applicable in your case) would be to have your own idp, which then federates out to the iDPs that belong to your customers. The customer’s idp deals with the
authentication, and your idp deals with the authorization - essentially (to oversimplify) exchanging the id_token from the customer’s idp for an access token with the correct authorization (and maybe an id_token issued by your own idp as well).<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">There is the token exchange RFC, <a href="https://datatracker.ietf.org/doc/html/rfc8693">
https://datatracker.ietf.org/doc/html/rfc8693</a>, but I think the way you’d use this is to have your client talking to your own token endpoint it’s maybe not as big a win to have a standards based interface for that part.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<div>
<p class="MsoNormal"><span class="apple-tab-span"> </span>• Do OpenID / OAuth2 off-the-shelf products / services allow to create custom tokens? The question is not just if there is SOME product able to do that, but if that is a standardized functionality
of OpenID / OAuth2.<o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I don’t think there’s really any standards-defined way to do exactly what you ask (other than the above model, where you have your own idp in addition to the customer’s one - and the UMA one that Cal mentioned, but I’m not sure if you’d
be able to apply UMA in your situation as I think it would need your customer’s iDPs to support UMA).<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Thanks<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Joseph<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">On 18 May 2022, at 12:24, [Quipsy] Markus Karg <<a href="mailto:karg@quipsy.de">karg@quipsy.de</a>> wrote:<o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">Joseph,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">thanks a lot for your kind answer. We really appreciate all ideas!<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Actually we need to say that we are an ISV, so we are NOT in the position of selecting an IDP vendor. What we actually strive for is understanding the general OpenID / OAuth2 pattern, how we can integrate into ANY existing company infra
structure for SSO. Our customers all over the world already have chosen their IDPs to implement SSO, so there is NO SINGLE IDP and no choice BY US. They expect from us that our highly complex per-function-grants still work well with their particular IDP OR
that the IDP only does SSO but not authorization. In particular, they do NOT enforce to manage access rights within their IDP; i. e. it is OK for them to just create ID Token with their particular IDP, forward the ID Token to us, and let us do authorization
on our own in a custom way (if no better solution possible).<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Moreover, as we are dedicated open source committers, we strive for a free solution. So paying someone for answers on the OpenID / OAuth2 standards is out of scope for us. We do not have custom questions or product specific question, we
only ask about the standards themselves. So we like to abstain from project-specific consulting / vendor-specific solutions.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Hence our questions more clearly actually are:<o:p></o:p></p>
</div>
<ul type="disc">
<li class="MsoListParagraph" style="mso-list:l0 level1 lfo1">Is there something in OpenID / OAuth2 that fulfils per-function-grants, or do these standards only define RBAC?<o:p></o:p></li><li class="MsoListParagraph" style="mso-list:l0 level1 lfo1">Does OpenID / OAuth2 allow the separation of the authorization endpoint vendor from the token endpoint vendor? If yes, we would implement our own token endpoint producing our custom authorization
tokens in exchange for a standardized ID Token obtained from the IDP.<o:p></o:p></li><li class="MsoListParagraph" style="mso-list:l0 level1 lfo1">Do OpenID / OAuth2 off-the-shelf products / services allow to create custom tokens? The question is not just if there is SOME product able to do that, but if that is a standardized functionality of
OpenID / OAuth2.<o:p></o:p></li></ul>
<div>
<p class="MsoNormal">Thanks!<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">-Markus<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<div>
<p class="MsoNormal"><b>Von:</b><span class="apple-converted-space"> </span>Joseph Heenan <<a href="mailto:joseph@authlete.com">joseph@authlete.com</a>><span class="apple-converted-space"> </span><br>
<b>Gesendet:</b><span class="apple-converted-space"> </span>Mittwoch, 18. Mai 2022 10:26<br>
<b>An:</b><span class="apple-converted-space"> </span>[Quipsy] Markus Karg <<a href="mailto:karg@quipsy.de">karg@quipsy.de</a>><br>
<b>Cc:</b><span class="apple-converted-space"> </span><a href="mailto:general@lists.openid.net">general@lists.openid.net</a><br>
<b>Betreff:</b><span class="apple-converted-space"> </span>Re: [OpenID] Beginner's Question: Per-Function-Access-Rights<o:p></o:p></p>
</div>
</div>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Hi Markus<o:p></o:p></p>
</div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">The question you ask is perhaps deceptively simple. I think probably most commercial iDPs should have a solution that fits your needs, but they won’t necessarily all have the same solution, depending on the exact performance / security
/ user experience needs. It’s probably a little hard to give much in the way of concrete advice without a lot more info about your goals.<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">The general starting position is normally that the OpenID Connect id_token contains the details of the authentication event, and the OAuth2 access token (generally issued as part of the same flow) represents the authorisation(s). (For various
reasons this distinction isn’t always that clear.) The ID Token is generally expected to be consumed by the client, whereas the access token is expected to be consumed by the resource server(s) / API endpoints.<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">The simple solution is likely that your authorization server directly issues an access token that is the ‘custom authorization token containing the roles AND the per-function-grants’ (this could be a JWT/similar access token that directly
contains all the details, or an opaque token that can be introspected to see what the user has access to - the latter is perhaps along the lines you describe in ‘C’, most API gateways should support token introspection as defined in<span class="apple-converted-space"> </span><a href="https://datatracker.ietf.org/doc/html/rfc7662"><span style="color:purple">https://datatracker.ietf.org/doc/html/rfc7662</span></a><span class="apple-converted-space"> </span>).<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">There’s generally a lot to consider when picking your solution here, particularly as you’re likely to be stuck with whatever solution you implement for a long time - it’d probably be worthwhile to engage with the pre-sales process at a
particular vendor, who should be able to give you guidance on the best way to address your use cases with their solution, or to engage with a vendor neutral consultant that could help you select the best vendor - there’s a few on the OpenID Foundation members
list,<span class="apple-converted-space"> </span><a href="https://openid.net/foundation/sponsoring-members/"><span style="color:purple">https://openid.net/foundation/sponsoring-members/</span></a> <o:p></o:p></p>
</div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">Cheers<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">Joseph<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><br>
<br>
<br>
<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal">I am new to OpenID and OAuth2 and read several tutorials and references but there is one problem left open I hope you can help with.<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">Our existing application does RBAC with the addition of a complex system of functionality-grained access rights. This means, an authentication token must contain not only roles a user has, but also additional functionalities he is allowed
to do. Example: A user that is in the role „Editor“ might have (or might not have) the additional right to execute a special function X. As our application is huge, besides lots of roles there are literally hundred of optional functionalities he could be granted
or not. To our knowledge, this is not covered by any of the existing authentication services / products.<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">We did not find a solution for this in „pure“ OpenID Connect / OAuth2, so currently we discuss the following attempts:<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<ol style="margin-top:0cm" start="1" type="A">
<li class="MsoListParagraph" style="margin-top:0cm;margin-bottom:0cm;margin-bottom:.0001pt;mso-list:l2 level1 lfo2">
Let OpenID Connect do ONLY Authentication but not Authorization. This means, our client sends the obtained ID Token to our existing custom authorization service in exchange for a custom authorization token containing the roles AND the per-function-grants.<o:p></o:p></li></ol>
<div style="margin-left:36.0pt">
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<ol style="margin-top:0cm" start="2" type="A">
<li class="MsoListParagraph" style="margin-top:0cm;margin-bottom:0cm;margin-bottom:.0001pt;mso-list:l1 level1 lfo3">
Let OpenID Connect do BOTH Authentication and Authorization, but wrap each single function-based-grant as a role. In the end, this means a token needs to contain literally hundred of roles in turn, which makes it unmanageable in literally all OpenID Connect
services / products we evaluaged so far.<o:p></o:p></li></ol>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<ol style="margin-top:0cm" start="3" type="A">
<li class="MsoListParagraph" style="margin-top:0cm;margin-bottom:0cm;margin-bottom:.0001pt;mso-list:l3 level1 lfo4">
Maybe there is a standardized flow that allows an authorization service dynamically lookup the function-based-grant from our custom authorization service?<o:p></o:p></li></ol>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">Maybe there are other solutions to that problem, but we could not image them.<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">Any comments welcome (besides: do not use per-function-access-rights as this is axiomatic for our product)!<span class="apple-converted-space"> </span><span style="font-family:"Segoe UI Emoji",sans-serif">😊</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">-Markus<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif">_______________________________________________<br>
general mailing list<br>
</span><a href="mailto:general@lists.openid.net"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif;color:purple">general@lists.openid.net</span></a><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif"><br>
</span><a href="https://lists.openid.net/mailman/listinfo/openid-general"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif;color:purple">https://lists.openid.net/mailman/listinfo/openid-general</span></a><o:p></o:p></p>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</body>
</html>