OAuth WG Interim Meeting

Date

26 April, 2021, 12:00pm EDT

Topic - TMI BFF

Presenters: Vittorio/Brian
Draft: https://datatracker.ietf.org/doc/draft-bertocci-oauth2-tmi-bff/
Slides: TMI BFF

Notes

Note taker: Justin Richer

"Token Mediating and session Information Backend For Frontend"

Chair introduction

Next week's meeting (OAuth 2.1) is cancelled for 5/3, an updated meeting will be scheduled when the team is ready

TMI BFF (Vittorio)

• mechanism for a JS frontend to delegate token request/storage to backend, but still call directly from the frontend

• common practice already, this draft gives guidance

  • prevent obvious security issues

• some interpret "BFF" as backend does absolutely everything

  • not how we use it in the draft
  • that pattern is "Full BFF", this spec does not describe or replace a full BFF
  • BFF means "you have a backend that does some work"

Why?

• Whenever possible, keep tokens out of frontend
  • but not always possible
  • people solve these topologies in different ways
• code+PKCE is nice but complex
• Common workaround:
  • obtain tokens on the backend, pass to the frontend
  • no threat model, no common mitigations
  • no way to "just reuse" stuff
• goal: provide some guidance
  • acheive some interoperability
  • enshrine security principles
• adds two endpoints

Main Flow

• front end and back end are same application
• requires session before anything else
• backend gets tokens (AT/RT)
• front end requests token from backend
  • no client ID, no configuration
• Backend checks session to associate with tokens
  • if a token can be sent, do so (with additional headers)
  • if a token isn't available without interaction, fail (for now, maybe more in the future?)
• Frontend can now call the API with the token
• session endpoint
  • frontend sends in cookie to get information of the user
  • backend sends back whatever it wants to about user

Advantages

• JS is simple (no config)
• two new additional endpoints
• calls can be made from frontend
• don't need to use the same advanced measures to protect things like PKCE and RT
• works with any signin/session

Changes in -01

• added security measures
• removal of security benefits claims
• clarified "Full BFF" and intentions
• explained prereqs
• clarified this expands explanation of browser BCP

What are we doing

• people are doing this today w/o guidance, two approaches
  • we find reasons nobody should do this at all, campaign against it
  • we find an acceptable approach, don't leave details to the implementers
• open issue: should we handle token aqcuisition case?
  • if interaction is needed when session token endpoint is called

Discussion

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

Wrap Up (Chairs)

Great discussion, would like to see more. Are we ready to adopt this as a WG document?

will call for adoption on list

Attendees

• Rifaat Shekh-Yusef (chair)
• Hannes Tschofenig (chair)
• Vittorio Bertocci (presenter)
• Justin Richer
• Dick Hardt
• Filip Skokan
• Karsten Meyer zu Selhausen
• Peter Yee
• Aaron Parecki
• Heather Flanagan
• Torsten Lodderstedt
• Brian Campbell
• Marius Ciocan
• Cristofer Gonzales
• George Fletcher
• Roberto Polli

Recording

https://ietf.webex.com/ietf/ldr.php?RCID=428ca38bc18c40cab2660b4ac87b5d9f