26 April, 2021, 12:00pm EDT
Presenters: Vittorio/Brian
Draft: https://datatracker.ietf.org/doc/draft-bertocci-oauth2-tmi-bff/
Slides: TMI BFF
Note taker: Justin Richer
"Token Mediating and session Information Backend For Frontend"
Next week's meeting (OAuth 2.1) is cancelled for 5/3, an updated meeting will be scheduled when the team is ready
common practice already, this draft gives guidance
some interpret "BFF" as backend does absolutely everything
Dick: BFF design pattern means "full BFF", suggest different acronym, we won't be able to change that
... surprised to see .well-known as API endpoint instead of discovery endpoint
... if we are going to use .well-known, do we add more about heirarchy? like add /oauth/...
Vittorio: BFF name is a known issue; TMI and BFF are common outside of our world, but we have good placement within our space
... on .well-known, no preference
Brian: don't have strong opinion [on .well-known]
... there does seem to be general dislike for having functional APIs in .well-known
... it seemed silly to have a discovery document for two endpoints instead of two endpoints
... for namespacing, I believe you're not allowed paths in well-known registry (or name prefix?)
Dick: we may want to provide a rationale section
... most places think .well-known is static
... it's not required but people make assumptions
... maybe these two endpoints can go into the existing metadata file
Brian: this metadata is about an app not an existing OAuth component
... would deserve its own space or distinct treatment
... running afoul of other infrastructure is valid point to consider
Vittorio: discovery is more flexible, but in my experience many people use defaults
... all the guidelines rely on those defaults
Brian: potential for conflict is avoided by .well-known registry
... standardizing paths into application namespaces that's not in .well-known will be frowned on by IESG
... if we made this more static files-based it might play nicer
Dick: library can fetch discovery and gives endpoints more flexibility
Vittorio: if default is discovery instead of action endpoints, same to the front end developer
Aaron: agree with dick that .well-known is not required to be static but is often deployed in static way
... if an app is running at a subdirectory, team doesn't control the root
... would be difficult to route that root for an app
Aaron: PKCE never intends to claim that it protects tokens at rest, just tokens en route to application
... PKCE doesn't solve what this draft is solving, not an alternative to this pattern
... questions: session info endpoint, what is the value of this if it isn't more defined?
Vittorio: if you were to go further than just calling APIs, like wanting the frontend to know attributes in advance
... then having a fixed schema would help; however, that might be too restrictive
... as an example, Klout; had all apps to sign in to get social scores, had oauth on top of it
... if we were to constrain into schema, we'd have a problem since we might have something completely different
... leaving to the developer "what is a user" is part of the power to this approach
Aaron: maybe making suggestions like "if you are using OIDC, do it this way"
... if people come with a minimum set of properties, it would give more interop at that layer
... if you're not in that realm, forcing schemas doesn't help
Vittorio: these endpoints are useful also when you aren't calling APIs outside your domain, you're calling things in your own backend
... but normally when I use OAuth I'm using useinfo in the JS, I don't get that from cookies
... formalizing this gives them a way to get that in a way that's standardized
Aaron: question: one benefit is to have shared security knowledge, do you have a list of things NOT to do instead of this?
Vittorio: list of security considerations, like asking for additional scopes
... also things like a the headers to protect from CSRF and similar
Brian: on sessioninfo, valid benefits for keeping it open and defining what's there
... maybe define a small subset of claims to be recommended/required
... like a logout button with "you are logged in as DisplayName" to always count on
... there will always be some notion of "who you are"
Vittorio: proposal: instead of having a super-basic GET, what if we have a "strict GET / loose GET"
... strict is all the guarantees, loose is whatever you want
Aaron: are you concerned about conflicts in property names?
... Brian was suggesting minimum set that you rely on
Brian: super minimum
Vittorio: I had so many problems mapping values from providers
... had same concepts with different names, finding that core is challenging
... I'm concerned with privacy, like "only thing you get is unique identifier"
... not confident we can get that schema
Torsten: would like to understand what attacks proposed service prevents and doesn't prevent
... for example you keep the refresh token out of the browser but put access token into the browser, so it can still leak
Vittorio: fair assessment, means you can get access token when you have a session cookie
... but you could use the same attack directly if you facade the API calls
... this doesn't prevent cookie-based attacks, but relies on the same checks
Torsten: you could extract the access token to play somewhere else, though
... question, how do you detect and handle revoked access tokens
Vittorio: that is all handled on the back end
... the back end is responsible for token based checks
... we are just making some parts available to a different component
Torsten: say the front end detects a token doesn't work, how does the backend detect this?
Vittorio: we don't address this, there is no signal from the front end to back end to signal
Torsten: otherwise the front end will run a loop
... token fails, front end calls backend, backend returns same token, front end loops with failing token
Vittorio: should you let the front end send an error/response or a flag to say "give me a fresh one"
Torsten: instinct says send errors, but we should discuss this
Vittorio: people using this are not sophisticated
Torsten: simple solution is another parameter, like resetAccessToken, more sophisticated would let backend do more processing
Filip: it sometimes is not possible to control .well-known
... would you consider fallback, like information returned in HTML of page (like head/meta tag)
... served from the backend with the frontend app
... for scenarios I don't control well-known this would be great
Dick: that's a great idea
Vittorio: any mechanism works, main constraint is that it should be easy to package into SDKs
... want to prevent developers choosing different ways and not talking to each other
Great discussion, would like to see more. Are we ready to adopt this as a WG document?
will call for adoption on list
https://ietf.webex.com/ietf/ldr.php?RCID=428ca38bc18c40cab2660b4ac87b5d9f