# 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](https://datatracker.ietf.org/meeting/interim-2021-oauth-09/materials/slides-interim-2021-oauth-09-sessa-tmi-bff-00) # 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