<div dir="ltr"><div dir="ltr">On Tue, Sep 22, 2020 at 2:37 PM Wessel, Keith <<a href="mailto:kwessel@illinois.edu">kwessel@illinois.edu</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
I'd love for someone to inform me that it's wrong to protect this flow. If not, I'll propose a feature in Jira for an IdP admin flow. You're very right: that would be much cleaner than what I'm doing here.<br></blockquote><div><br></div><div>It's not wrong to protect the client registration endpoint.  However, the spec does say it should be via an "initial access token":</div><div class="gmail_quote"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">3.  Client Registration Endpoint<br>The Client Registration Endpoint is an OAuth 2.0 Protected Resource through which a new Client registration can be requested. <b>The OpenID Provider MAY require an Initial Access Token that is provisioned out-of-band (in a manner that is out of scope for this specification) to restrict registration requests to only authorized Clients or developers.</b><br>To support open Dynamic Registration, the Client Registration Endpoint SHOULD accept registration requests without OAuth 2.0 Access Tokens. These requests MAY be rate-limited or otherwise limited to prevent a denial-of-service attack on the Client Registration Endpoint. If an Initial Access Token is required for Client registration, the Client Registration Endpoint MUST be able to accept these Access Tokens in the manner described in the OAuth 2.0 Bearer Token Usage [RFC6750] specification.</blockquote><div> </div><div>(<a href="https://openid.net/specs/openid-connect-registration-1_0.html#ClientRegistration">https://openid.net/specs/openid-connect-registration-1_0.html#ClientRegistration</a>)<br></div><div><br></div><div>As an example, our OP/AS implementation (Connect2id) offers a couple of mechanisms for obtaining initial access tokens.  There are some static ones for admin-level requests, and then they can also be generated through the use of other clients, which is nice, because you can also put some limits on the metadata components that can be registered.  ("Nice" to have, I guess, though we actually haven't handed any out.  We've registered all of our clients to date.)</div><div><br></div><div>That said, I don't think the OIDF has formed a police force that's going to come knocking if you protect the endpoint some other way.  I think the biggest problem will come from users of RP code that won't know how to navigate something other than the access token-based access.</div><div><br></div><div>Greg</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
</blockquote></div></div>