You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: draft-ietf-oauth-browser-based-apps.md
+12-10Lines changed: 12 additions & 10 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -377,29 +377,30 @@ Remarks and mitigations:
377
377
* The application designer SHOULD consider not having refresh tokens at all to avoid the risk of giving prolonged access to the attacker.
378
378
379
379
### Tokens Securely Handled by a Service worker
380
-
In this scenario, a [Service Worker](https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API) is responsible for obtaining tokens from the authorization server and passing them to the resource API.
380
+
In this scenario, a [Service Worker](https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API) is responsible for obtaining tokens from the authorization server and making requests to the resource server.
381
381
382
-
Service workers are inherently safe from XSS, because the browser APIs allowing to register one take an origin-constrained URL.
383
-
They can thus be used as a safe store for tokens.
382
+
Service workers are run in a separate context from the DOM, have no access to the DOM, and the DOM has no access to the service worker. This makes service workers inherently safe from XSS, thus they can be used as a safe store for tokens.
384
383
385
-
In this architecture, a service worker intercepts calls from the frontend to the resource server. As such, it completely isolates calls to the authorization server from XSS attack surface, as all tokens and PKCE secrets are safely kept there without any access from other JavaScript contexts. The service worker is then solely responsible for adding authentication headers to calls to the resource server.
384
+
In this architecture, a service worker intercepts calls from the frontend to the resource server. As such, it completely isolates calls to the authorization server from XSS attack surface, as all tokens are safely kept in the service worker context without any access from other JavaScript contexts. The service worker is then solely responsible for adding the token in the authorization header to calls to the resource server.
| |-------------------> resource request with token | |
400
401
| | | ---------------------------->| |
401
402
| | | | |
402
-
User Application Service Worker Resource Authorization
403
+
User Application Service Worker Resource Authorization
403
404
server server
404
405
405
406
#### Security Considerations
@@ -409,6 +410,7 @@ In this architecture, a service worker intercepts calls from the frontend to the
409
410
* The service worker MUST not transmit tokens, authorization codes or PKCE secrets (e.g. code verifier) to the frontend application.
410
411
* The service worker MUST block /token or /authorize calls initiating from the frontend application in order to avoid any front-end side-channel for getting credentials: the only way of starting the authorization flow is through the service worker. This protects against re-authorization from XSS-injected code.
0 commit comments