I’m seeing broader need for discovery of OAuth infrastructure for APIs in general now that APIs are being deployed by many parties: * based on a standard (e.g. SCIM, IMAP, SMTP) * Implemented in open source and deployed by many (e.g. K8S and its various components). * Services like streaming (Kakfa) * Serverless/microservices APIs
I agree, that having some process where the RS can indicate to a client where to go do discovery would be helpful. The issue is somewhat complex and we have talked about some of this before. For example, an RS may have multiple AS’s it accepts tokens from. Does the RS indicate many or specific discovery endpoint that may or may not involve registration (in order to determine the appropriate AS)? How is the metadata secured? How do we ensure we haven’t opened up an automated attack point (e.g. a MITM’d RS gives a client false discovery information). Phil Oracle Corporation, Cloud Security and Identity Architect @independentid www.independentid.com <http://www.independentid.com/>phil.h...@oracle.com <mailto:phil.h...@oracle.com> > On Nov 7, 2018, at 1:08 PM, George Fletcher > <gffletch=40aol....@dmarc.ietf.org> wrote: > > Related to this discussion of AS discovery... what is the value of using the > Link response header over just returning the variables in the > WWW-Authenticate header? Could we not use... > > WWW-Authenticate: OAuth realm="example_realm", scope="example_scope", > error="invalid_token", rs_uri="https://api.example.com/resource"; > <https://api.example.com/resource>, > as_uri="https://as1.example.com,https://as2.example.com"; > <https://as1.example.com,https//as2.example.com> > > Thanks, > George > > On 11/6/18 12:19 AM, Justin P Richer wrote: >> In the meeting tonight I brought up a response to the question of whether to >> have full URL or plain issuer for the auth server in the RS response’s >> header. My suggestion was that we have two different parameters to the >> header to represent the AS: one of them being the full URL (as_uri) and one >> of them being the issuer to be constructed somehow (as_issuer). I ran into a >> similar problem on a system that I built last year where all of our servers >> had discovery documents but not all of them were easily constructed from an >> issuer style URL (using OIDC patterns anyway). So we solved it by having two >> different variables. If the full URL was set, we used that; if it wasn’t, we >> tried the issuer; if neither was set we didn’t do any discovery. >> >> I’m sensitive to Torsten’s concerns about complexity, but I think this is a >> simple and deterministic solution that sidesteps much of the issue. No pun >> intended. >> >> — Justin >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org <mailto:OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth >> <https://www.ietf.org/mailman/listinfo/oauth> > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
