[OAUTH-WG] Client authentication on token revocation
Hi all, We are currently implementing the token revocation endpoint (RFC 7009) on our authorization server and do not understand why it requires client authentication. When a party (a valid client or not) gets hold of a valid access token in whatever way, the least damaging it could do with it, is to revoke it. The current spec allows an attacker to misuse this token for access to the resource server, but forbids it to revoke it. This seems strange to me. Section 5 of RFC 7009 does not help in this either. It starts to explain that this authentication is needed to prevent malicious clients from guessing tokens, but ends with the fact that if this were possible, much worse damage could be done by using the guessed token on the resource server. We plan to skip the authentication all together and simply revoke any valid token presented. How would you recommend we deal with this? Best regards, Emond Papegaaij Topicus KeyHub ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Client authentication on token revocation
Hi Torsten, Thanks for your insight. I agree, a sender constraint token, such as when using certificate bound tokens from RFC 8705, cannot be used by an attacker. It makes sense to only allow the owner to revoke them, probably using the same mechanism as by which they are bound to the client. For bearer tokens, we will simply skip the validation of the client credentials. Best regards, Emond Papegaaij On Thu, Aug 20, 2020 at 12:52 PM Torsten Lodderstedt wrote: > > Hi Emond, > > I tend to agree with your assessment. Revoking bearer tokens without client > authentication seems to be better than leaving the attacker the option to use > them to invoke resources. > > However, if the attacker cannot use the access tokens (e.g. because they are > sender constrained), the attacker could revoke tokens issued to a > confidential client as a kind of DoS attack. > > best regards, > Torsten. > > > On 20. Aug 2020, at 11:02, Emond Papegaaij > > wrote: > > > > Hi all, > > > > We are currently implementing the token revocation endpoint (RFC 7009) > > on our authorization server and do not understand why it requires > > client authentication. When a party (a valid client or not) gets hold > > of a valid access token in whatever way, the least damaging it could > > do with it, is to revoke it. The current spec allows an attacker to > > misuse this token for access to the resource server, but forbids it to > > revoke it. This seems strange to me. > > > > Section 5 of RFC 7009 does not help in this either. It starts to > > explain that this authentication is needed to prevent malicious > > clients from guessing tokens, but ends with the fact that if this were > > possible, much worse damage could be done by using the guessed token > > on the resource server. We plan to skip the authentication all > > together and simply revoke any valid token presented. How would you > > recommend we deal with this? > > > > Best regards, > > Emond Papegaaij > > Topicus KeyHub > > > > ___ > > 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
Re: [OAUTH-WG] [Technical Errata Reported] RFC7009 (6663)
On Mon, Aug 23, 2021 at 9:42 PM Justin Richer wrote: > I personally don’t agree with this errata. Token Revocation was never > meant to act as a protected resource, but rather as a function of the AS. > The client is known to the AS and so authentication is expected here. > We ran into this very issue some time ago. Our client in this case was a command line tool, which only requests the client credentials on login. It then fetches an access token and stores this locally. The client credentials are not stored by default. The current spec required us to request the client credentials to revoke the access token on logout. Personally, I see no point in requiring the the client to authenticate, it already possesses an access token, which it can use for whatever it wants to and the possession of the token should be enough evidence that the client previously authenticated. Revoking the token seems to be the least harmful one can do with a token. For more information see: https://mailarchive.ietf.org/arch/msg/oauth/7qxGcptE-uzA5WQaxnzGMdSqb2I/ Best regards, Emond Papegaaij > > On Aug 22, 2021, at 5:14 AM, RFC Errata System < > rfc-edi...@rfc-editor.org> wrote: > > > > The following errata report has been submitted for RFC7009, > > "OAuth 2.0 Token Revocation". > > > > -- > > You may review the report below and at: > > https://www.rfc-editor.org/errata/eid6663 > > > > -- > > Type: Technical > > Reported by: Ashvin Narayanan > > > > Section: 2.1 > > > > Original Text > > - > > The client constructs the request by including the following > > parameters using the "application/x-www-form-urlencoded" format in > > the HTTP request entity-body: > > > > token REQUIRED. The token that the client wants to get revoked. > > > > token_type_hint OPTIONAL. A hint about the type of the token > > submitted for revocation. Clients MAY pass this parameter in > > order to help the authorization server to optimize the token > > lookup. If the server is unable to locate the token using > > the given hint, it MUST extend its search across all of its > > supported token types. An authorization server MAY ignore > > this parameter, particularly if it is able to detect the > > token type automatically. This specification defines two > > such values: > > > > * access_token: An access token as defined in [RFC6749], > > Section 1.4 > > > > * refresh_token: A refresh token as defined in [RFC6749], > > Section 1.5 > > > > Specific implementations, profiles, and extensions of this > > specification MAY define other values for this parameter > > using the registry defined in Section 4.1.2. > > > > The client also includes its authentication credentials as described > > in Section 2.3. of [RFC6749]. > > > > For example, a client may request the revocation of a refresh token > > with the following request: > > > > POST /revoke HTTP/1.1 > > Host: server.example.com > > Content-Type: application/x-www-form-urlencoded > > Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW > > > > token=45ghiukldjahdnhzdauz&token_type_hint=refresh_token > > > > The authorization server first validates the client credentials (in > > case of a confidential client) and then verifies whether the token > > was issued to the client making the revocation request. If this > > validation fails, the request is refused and the client is informed > > of the error by the authorization server as described below. > > > > Corrected Text > > -- > > The client calls the revocation endpoint using an HTTP > > POST [RFC7231] request with the following parameters sent as > > "application/x-www-form-urlencoded" data in the request body: > > > > token REQUIRED. The token that the client wants to get revoked. > > > > token_type_hint OPTIONAL. A hint about the type of the token > > submitted for revocation. Clients MAY pass this parameter in > > order to help the authorization server to optimize the token > > lookup. If the server is unable to locate the token using > > the given hint, it MUST extend its search across all of its > > supported token types. An authorization server MAY ignore > >
Re: [OAUTH-WG] [Technical Errata Reported] RFC7009 (6663)
On Tue, Aug 24, 2021 at 12:14 PM Warren Parad wrote: > I think it is worth pointing out, if we were to agree with the errata, > that this particular use case probably isn't relevant: > > Our client in this case was a command line tool, which only requests the >> client credentials on login. It then fetches an access token and stores >> this locally. The client credentials are not stored by default. > > > Unless I misunderstand, I'll take "client credentials" to mean client Id > and client credentials via a client credentials grant. And therefore, is > not the correct flow to be used in a command line tool. Client credentials > are used in private when there are many user agents that could connect > through it, I would not recommend this as the solution here, and even if it > were, you would indeed have access to the client id and secret, so it would > not be a problem to use them to revoke the token. > The CLI-tool actually supports both a 3-legged (via the device authorization grant) and a 2-legged flow (via the client credentials grant). It depends on the use case which one is appropriate. In the case of a user logging in to access the application via the CLI, it clearly is the 3-legged flow, however when the CLI is used in a script that runs without user interaction, it's the 2-legged flow. In this later case, the script often fetches the credentials from some store, uses them to acquire an access token, does it job, and revokes the token. Naturally, it can fetch the credentials a second time to revoke the token, but I really don't see the point in this case. The client merely indicates it is done with the token and it can now be revoked. It is good practice to discard any credentials when you are done with them to minimize the chance of abuse. However, requiring the client authentication to revoke the token, really complicates this case and will probably lead to scripts not revoking the token. > However, I believe there is something fundamentally broke here, because > there are two use cases which are in conflict with each other: > >- I as a user, at any time want to revoke one of, access token, >refresh token, or granted scopes associated with my identity by directly >communicating with an AS. I never want to make this request through a >client, and more specifically, I never want a client to determine whether >or not I'm allowed to revoke these. >- I as a user, at no time want to allow a client, for whom I did not >give permission to revoke my refresh token nor revoke granted scopes. It >should not be the case that one client sharing the token with another >client (either intentionally or accidentally) would be allowed to change >the requested scopes nor make decisions about the validity of my current >access token or delegated refresh token. > > Given the latter we see that it must be the case that refresh tokens, > access tokens, and associated grants MUST NOT be allowed to be revoked > without client authentication. This means that the original RFC is indeed > correct, and that the errata is not. But, this does not enable the former > case nor encourage a solution that works in scope of retaining control over > resources that the user agent owns. However, it is worth mentioning that it > doesn't prevent, as it still allows an AS to implement additional > mechanisms for direct user revocation, if desired. > > That being said I would be in favor of enumerating a *flow* to safely > instruct the AS to revoke directly by the user, but it cannot be done by > amending the revocation endpoint. > I don't fully understand your statement here. As far as I understand the token revocation endpoint, it is an endpoint specifically for the client to be used when it no longer needs the token. The client can simply discard the tokens, but it is cleaner to inform the AS about this fact and allow the AS to cleanup its resources as well. It is in no way an endpoint to be used by the resource owner to revoke access for certain clients. I see it like returning a key when you no longer need access to a building. The fact that you hold the key should be enough for you to be able to return it. I do want to point out that the spec for bearer tokens states: "A security token with the property that any party in possession of the token (a "bearer") can use the token in any way that any other party in possession of it can." Clients should IMHO not be exchanging tokens with another party unless they really trust this other party, in which case they should also trust this party not to revoke the tokens when not agreed upon. If any malicious party would get hold of my tokens, I wish they would only use them to revoke them. A leaked token should be revoked anyway. One could even
[OAUTH-WG] OAuth 2.0 Device flow error response
Dear all, I'm working on an implementation of the OAuth 2.0 Device Flow for Browserless and Input Constrained Devices and noticed a possible omission in the spec. Section 3.2 describes the Device Authorization Response, but only the success response is specified, not the error response. I would have expected a standard OAuth 2.0 error response, probably with the following error codes: invalid_request, invalid_client and invalid_scope. Best regards, Emond Papegaaij Topicus KeyHub ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] OAuth 2.0 Device flow error response
Yes, that's how I implemented it as well. I return 'invalid_request' when the client_id is missing entirely. Do you have any thoughts how this specification should work in combination with other specs, such as OIDC? For example, the OIDC Authentication Request specifies several additional parameters, some of which may be applicable for the device flow as well. Can the device flow be used to obtain an ID token? How should parameters like 'max_age', 'id_token_hint' and 'claims' be processed? My plan was to construct a pseudo-authentication/authorization request using the parameters specified at the device authorization endpoint and apply these parameters during the user interaction. Some parameters, such as 'prompt=3Dnone', do not make much sense though. I think it may be a good idea to describe how this spec is supposed to interoperate with other specifications, especially those that extend the Authorization Endpoint. This definition can never be complete, as new specs will be defined after this one, but it can at least try to describe the general rules that apply. PS. Other specifications also define additional parameters that may be useful, such as: 'resource' from Resource Indicators for OAuth 2.0 and 'include_granted_scopes' from OAuth 2.0 Incremental Authorization. Best regards, Emond Papegaaij Topicus KeyHub On Fri, Mar 8, 2019 at 10:24 PM Brian Campbell wrote: > > While probably not terribly important from an interoperability perspective, I > agree that does seem like an omission. > > I took a quick look at our implementation and bad requests to the device > authorization endpoint will indeed return what is a standard OAuth 2.0 error > response normally from the token endpoint with invalid_client or > invalid_scope error codes. And a little bit of poking at Google's device > authorization endpoint suggests it behaves similarly. I suspect it's pretty > typical. > > > > On Fri, Mar 8, 2019 at 5:28 AM Emond Papegaaij > wrote: >> >> Dear all, >> >> I'm working on an implementation of the OAuth 2.0 Device Flow for Browserless >> and Input Constrained Devices and noticed a possible omission in the spec. >> Section 3.2 describes the Device Authorization Response, but only the success >> response is specified, not the error response. I would have expected a >> standard OAuth 2.0 error response, probably with the following error codes: >> invalid_request, invalid_client and invalid_scope. >> >> Best regards, >> Emond Papegaaij >> Topicus KeyHub >> >> >> ___ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > > CONFIDENTIALITY NOTICE: This email may contain confidential and privileged > material for the sole use of the intended recipient(s). Any review, use, > distribution or disclosure by others is strictly prohibited. If you have > received this communication in error, please notify the sender immediately by > e-mail and delete the message and any file attachments from your computer. > Thank you. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Typo in Device flow 5.2
Hi all, It seems the word 'no' is missing in section 5.2 of the OAuth 2.0 Device flow: As the device code is not displayed to the user and thus there are *NO* usability considerations on the length, a very high entropy code SHOULD be used. Best regards, Emond Papegaaij Topicus KeyHub ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] OAuth 2.0 Device flow error response
Hi Filip, Yes, this was exactly what I was thinking about. Good to know I'm working in the right direction. I must say that the spec reads really well and is fairly straightforward to implement. Best regards, Emond Papegaaij Topicus KeyHub On Mon, Mar 11, 2019 at 6:29 PM Filip Skokan wrote: > > Hi Emond, > > the way i approached implementation of device flow into an OIDC server was to > allow all already registered and handled parameters excluding the ones [1] > that really don't make sense for the flow at the device authorization > endpoint. > > What can be validated at the device authorization endpoint time is, > everything else runs as part of the regular authorization pipeline for which > i also construct the request based on the params saved together with the > device code backend model. Everything else that depends on the actual device > where authnz happens is processed as part of the web request following the > user code submission. When errors occur that cannot be resolved with user > interaction the error is assigned to the device code and returned to the > device with the next poll. I did not exclude prompt:none, as the pipeline > processing starts after the submission it's possible that no prompt will > occur there, but i can see how it may be weird. Yes the result at the token > endpoint will include an id token if the scope included `openid` as one would > expect, just like it will include a refresh token if `offline_access` is > present. `resource` specifically is available as per the resource indicator > spec at device authorization as well as token endpoints. > > I guess this is very similar to what you're thinking. > > I don't think we need to (and can for that matter) enumerate all possible > OAuth2.0 extensions in the specification. > > [1] web_message_uri, web_message_target, response_type, response_mode, state, > redirect_uri > > S pozdravem, > Filip Skokan > > > On Mon, 11 Mar 2019 at 15:02, Emond Papegaaij > wrote: >> >> Yes, that's how I implemented it as well. I return 'invalid_request' >> when the client_id is missing entirely. >> >> Do you have any thoughts how this specification should work in >> combination with other specs, such as OIDC? For example, the OIDC >> Authentication Request specifies several additional parameters, some >> of which may be applicable for the device flow as well. Can the device >> flow be used to obtain an ID token? How should parameters like >> 'max_age', 'id_token_hint' and 'claims' be processed? My plan was to >> construct a pseudo-authentication/authorization request using the >> parameters specified at the device authorization endpoint and apply >> these parameters during the user interaction. Some parameters, such as >> 'prompt=3Dnone', do not make much sense though. >> >> I think it may be a good idea to describe how this spec is supposed to >> interoperate with other specifications, especially those that extend >> the Authorization Endpoint. This definition can never be complete, as >> new specs will be defined after this one, but it can at least try to >> describe the general rules that apply. >> >> PS. Other specifications also define additional parameters that may be >> useful, such as: 'resource' from Resource Indicators for OAuth 2.0 and >> 'include_granted_scopes' from OAuth 2.0 Incremental Authorization. >> >> Best regards, >> Emond Papegaaij >> Topicus KeyHub >> >> On Fri, Mar 8, 2019 at 10:24 PM Brian Campbell >> wrote: >> > >> > While probably not terribly important from an interoperability >> > perspective, I agree that does seem like an omission. >> > >> > I took a quick look at our implementation and bad requests to the device >> > authorization endpoint will indeed return what is a standard OAuth 2.0 >> > error response normally from the token endpoint with invalid_client or >> > invalid_scope error codes. And a little bit of poking at Google's device >> > authorization endpoint suggests it behaves similarly. I suspect it's >> > pretty typical. >> > >> > >> > >> > On Fri, Mar 8, 2019 at 5:28 AM Emond Papegaaij >> > wrote: >> >> >> >> Dear all, >> >> >> >> I'm working on an implementation of the OAuth 2.0 Device Flow for >> >> Browserless >> >> and Input Constrained Devices and noticed a possible omission in the spec. >> >> Section 3.2 describes the Device Authorizatio
[OAUTH-WG] Token Exchange status and Resource Indicators
Hi all, For the application I work on, Topicus KeyHub, we are investigating 'OAuth 2.0 Token Exchange'. We want to use this protocol to exchange an access token for a SAML assertion for signing in to AWS (see below). However, I noticed that draft 16 has expired on April 22, 2019. Is this specification still active? While looking at the specification I noticed a partial overlap with 'Resource Indicators for OAuth 2.0'. Both specify the 'resource' parameter on the token endpoint. However, Token Exchange adds to this the 'audience' parameter. In my opinion it would make sense to align these specs and add the 'audience' parameter to 'Resource Indicators'. 'Token Exchange' could then continue to build on the 'Resource Indicators' spec rather than redefining these parameters. The specific use case I have in mind is acquiring a SAML assertion for AWS on the command line, using the following steps: Our CLI starts with the device authorization grant. In the device+ authorization request, it passes 'audience=urn:amazon:webservices', which is the entity ID for AWS. I could use 'resource' here, but I think 'audience' is more appropriate. Next, the user will continue the authentication and will be prompted for consent with signing a token for AWS. The resulting access token will be audience restricted to AWS. Finally, the CLI will exchange this token for a SAML assertion for AWS. I can again pass the desired audience, but as it is already encoded in the token, this is optional. This assertion can then be passed to AWS to complete the sign-in. To summarize, I have to following questions: - Is the 'OAuth 2.0 Token Exchange' specification still active? - Can 'audience' be added to 'Resource Indicators for OAuth 2.0'? - Can 'OAuth 2.0 Token Exchange' be updated to build on 'Resource Indicators for OAuth 2.0' rather than redefining the same parameters? Best regards, Emond Papegaaij Topicus KeyHub ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Token Exchange status and Resource Indicators
On zondag 5 mei 2019 15:54:48 CEST you wrote: > On Fri, May 3, 2019 at 9:39 AM Emond Papegaaij > > To summarize, I have to following questions: > > - Is the 'OAuth 2.0 Token Exchange' specification still active? > > Yes with the caveats mentioned above. I will say that although there's a > lot of work required for the document, none of it is likely to result in > functional changes so I don't anticipate anything breaking at this point. Good to hear, because IMHO it really adds value to OAuth 2.0. > > - Can 'audience' be added to 'Resource Indicators for OAuth 2.0'? > > No, that's beyond it's current scope. And it is well past last call in the > WG. But note that a logical identifier can be used as the value of the > resource parameter. Would you recommend to put the AWS entity id in the resource parameter on the authorize request then? I need a way to inform the authorization server that the client wants a token for a different service to allow the authorization server to prompt the user for correct consent. I like the 'audience' parameter defined by the token exchange specification, because it really fits the purpose I'm looking for. However, I also like to keep the authorization request and token request similar. It looks wrong to ask for authorization for 'resource' X and later on request a token for 'audience' X. Best regards, Emond Papegaaij ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Recommendations for OAuth 2.0 with Browser-Based Apps
Hi all, For a browser-based app, we try to follow the recommendations set in draft- ietf-oauth-browser-based-apps-01. This does allow us to create a secure OAuth 2.0 browser-based application, but at the moment it comes at a cost wrt. user experience when the access token expires. Our current solution forces us to redirect the user to the authorization server for a new authorization code. This will destroy most state the browser-based app has, causing the user to loose data. We are looking for a way to get a new access token in a secure way without disrupting the user. As a refresh token is not issued to the app (as it should be), the application is forced to do a front-channel re-authentication for an authorization code. We are thinking of letting this front-channel communication happen in a hidden iframe. Naturally, this can only be done if no user interaction is required, hence we want to use the OIDC prompt=none. Is this a viable way of doing this re-authentication? Can it hurt to open up our authorization server for non- interactive authorization requests inside an iframe? At the moment we do not allow iframes at all. Maybe anybody knows a different way of achieving this? As I cannot believe we are the only ones facing this issue, maybe a recommendation can be put in the spec? Best regards, Emond Papegaaij ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Recommendations for OAuth 2.0 with Browser-Based Apps
Hi, Thanks for your detailed reply. I've replied inline. On maandag 6 mei 2019 22:42:09 CEST David Waite wrote: > On May 6, 2019, at 1:42 PM, Emond Papegaaij wrote: > > For a browser-based app, we try to follow the recommendations set in > > draft- > > ietf-oauth-browser-based-apps-01. This does allow us to create a secure > > OAuth 2.0 browser-based application, but at the moment it comes at a cost > > wrt. user experience when the access token expires. Our current solution > > forces us to redirect the user to the authorization server for a new > > authorization code. This will destroy most state the browser-based app > > has, causing the user to loose data. We are looking for a way to get a > > new access token in a secure way without disrupting the user. > > As a refresh token is not issued to the app (as it should be), the > > application is forced to do a front-channel re-authentication for an > > authorization code. We are thinking of letting this front-channel > > communication happen in a hidden iframe. Naturally, this can only be done > > if no user interaction is required, hence we want to use the OIDC > > prompt=none. Is this a viable way of doing this re-authentication? Can it > > hurt to open up our authorization server for non- interactive > > authorization requests inside an iframe? At the moment we do not allow > > iframes at all. > > Some AS implementations will block authentication in an iframe, but will > allow you to use the OIDC prompt=none. This is already used quite often > today by implicit apps. It is possible that AS implementations may allow > iframes in the future, by detecting the frame is not covered with any > buttons, and having the authentication be based on phishing-resistant > authentication methods like W3C Web Authentication. Fortunately for us, we build the AS as well, so we are in control here. It is a bit unfortunate that this does depend on OIDC. Doing user interaction in an iframe seems like a snake pit I'd rather not go into. I think it's also bad wrt the user interaction. We do not want user to enter their credentials on any site that looks like our AS. Users should only enter their credentials when the URL matches or AS. > You could also trigger re-authorization with a user click, thus allowing > opening the AS in a new window or tab. Once back on the site via callback, > the temporary/pop-up window can do things like exchange the code for an > access token, persist it, postMessage the original window, do window.close, > etc. This would work, but would really be a nuisance to the user. Especially with a token timeout of just one hour. Also, most of the times there would be no interaction, the user would just have to click a button. As a user I wouldn't understand why I have to do that all the time. > On the other hand, refresh tokens IMHO are given quite a bit more fear in > browser apps than warranted. It really depends on the AS - whether it can > tie refresh tokens to the user’s authentication, or if they are tied to a > long-term / persisted / "offline” authorization independent of an active > user authentication. Currently, the latter is more common in > implementations, and doesn’t make sense for browser applications. This > doesn’t mean refresh tokens are automatically discounted for all > environments. How would you tie a refresh token to a user session on the AS? This would depend on the user visiting the AS on a regular basis and using a logout button when done. Most people simply close their browser when they're done, leaving the session open. Also, when making a call to the token endpoint to refresh the access token, there is no way of knowing that this call is actually initiated by the user, because it's done on a back channel. Perhaps this can be solved with DPOP with a keypair per browser, but this would really complicate the whole solution. > Given the choice between an 8 hour access token, or a 10 minute access token > and a refresh token that will expire at a maximum of 8 hours, the second > provides quite a few more options to be more secure. (eg. checking backing > user session and revocation, checking for updates to client blacklist, the > rotation of the access token, rotating refresh tokens to prevent use by > more than one client, expiring access on inactivity based on lag in > refreshing, and so on). I agree with you on this, but the spec currently states clearly that the AS should not issue refresh tokens to an SPA. Do you think this should be changed to something like: Authorization servers SHOULD NOT issue *offline* refresh tokens to browser-based applications. A refresh token should be tied to a user session on the AS. > If the refresh token is tied to the AS concept of u
Re: [OAUTH-WG] Token Exchange status and Resource Indicators
(reposting this to the list, due to an error on my part the mail got sent privately) > > > > - Can 'audience' be added to 'Resource Indicators for OAuth 2.0'? > > > > > > No, that's beyond it's current scope. And it is well past last call in > > > the WG. But note that a logical identifier can be used as the value > > > of the resource parameter. > > > > Would you recommend to put the AWS entity id in the resource parameter > > on the authorize request then? > > Yeah, that seems reasonable. The more I think about this solution, the more I get convinced it is not going to work in the general case. The main problem in this is that the resource parameter has a strict format: it MUST be an absolute URI. This works for SAML entity id's and OIDC issuers, but it will not work in the general form of a client identifier. Many of the client identifiers we use are UUIDs. There is no way to put this in the resource parameter on the authorize request. The library we use to implement our OAuth2 endpoints is very strict in this. Best regards, Emond Papegaaij ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Recommendations for OAuth 2.0 with Browser-Based Apps
On woensdag 8 mei 2019 22:55:47 CEST David Waite wrote: > > How would you tie a refresh token to a user session on the AS? This would > > depend on the user visiting the AS on a regular basis and using a logout > > button when done. Most people simply close their browser when they're > > done, > > leaving the session open. Also, when making a call to the token endpoint > > to > > refresh the access token, there is no way of knowing that this call is > > actually initiated by the user, because it's done on a back channel. > > Perhaps this can be solved with DPOP with a keypair per browser, but this > > would really complicate the whole solution. > > Yes, there are still no standard solutions for session keep-alive. There’s > also not AFAIK a clear solution by the browsers on how to do an implicit > logout on browser closed, now that browsers may persist sessions cookies. > > I did pitch something about session keep-alive two years ago around this as > part of DTVA (see > https://bitbucket.org/openid/connect/src/f76ffe99c47d4698bc2995c32dc7a402dd > 6e8c47/distributed-token-validity-api.txt > <https://bitbucket.org/openid/connect/src/f76ffe99c47d4698bc2995c32dc7a402d > d6e8c47/distributed-token-validity-api.txt> ), which unfortunately didn’t go > anyplace. For pure API apps participating in a session keep-alive system, a > separate “user activity present” API to periodically poke is probably the > best way to go. For managed devices running enterprise applications, you > can just have a screen lock rather than tracking session activity at all. This spec seems to make it possible to keep an active session. However, it is bound to OIDC, which will not work in our case. Many of the application we are IdP for use SAML. The spec relies on all parties communicating session activity. For now, OIDC session management seems to be the best way to go. > >> Given the choice between an 8 hour access token, or a 10 minute access > >> token and a refresh token that will expire at a maximum of 8 hours, the > >> second provides quite a few more options to be more secure. (eg. > >> checking backing user session and revocation, checking for updates to > >> client blacklist, the rotation of the access token, rotating refresh > >> tokens to prevent use by more than one client, expiring access on > >> inactivity based on lag in refreshing, and so on). > > > > I agree with you on this, but the spec currently states clearly that the > > AS > > should not issue refresh tokens to an SPA. Do you think this should be > > changed to something like: Authorization servers SHOULD NOT issue > > *offline* refresh tokens to browser-based applications. A refresh token > > should be tied to a user session on the AS. > > I would like this language changed as well. It is complex due to so little > existing token lifetime/policy guidance to reference. Previous > conversations went a bit circular IMHO because of a lack of ground rules. I can understand. This also highly depend on your use case. Something that might work for one application might be totally inappropriate for another. Best regards, Emond Papegaaij ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-browser-based-apps-03.txt
Hi all, After my vacation I've finally found time read up on the new BCP draft for browser based apps. First of all, thanks for the great work on this spec. I think this is a very important area to work on, as browser based applications are getting more and more common. Here's my feedback: 6.1. Apps Served from a Common Domain as the Resource Server This section has seen quite some comments, but IMHO one important aspect has not been emphasized enough: using an HTTP-only cookie to secure an API can make it very vulnerable to CSRF attacks. This was already mentioned by David Waite, but has not seen any response. Storing the access token (or session id, or whatever it is called when stored in a cookie) in an HTTP-only cookie will make it hard to steal, but also hard to protect from misuse. Any page can embed links to your API, and the browser will simply send the cookie. 'Traditional', server based, web applications require special protection against these kinds of attacks, but RESTful APIs often don't have such protection. IMHO advising to use a cookie to secure your API is therefore a dangerous advice. 8. Refresh Tokens This section also has seen a lot of comments. Why all this focus on the refresh token? All the attack vectors apply to the access token as well. If tokens cannot be stored securely in a browser based application, the authorization server should not issue any token at all. Leaking a single valid access token is likely to be more than enough for an attacker to get all the information he/she needs, even if it is only valid for a couple of minutes. Also, when an attacker manages to get an access token once, it is likely he/ she will succeed a second time (i.e. via an XSS attack). Placing these restrictions on refresh tokens, without addressing the access token seems senseless to me. I think this section should be about the lifetime of the authorization and detecting potential leaks of tokens. For a browser based application, I see no use at all for offline tokens. Without the browser, there is no application. Therefore the access should be scoped to the browser session, and this is IMHO best checked by the authorization server. At Topicus, we plan to implement this with short lived access tokens and performing re-authentication in a hidden iframe with prompt=none. The disadvantage of this is that is requires OIDC for the prompt parameter. In this setup we do not need refresh tokens, but other solutions may also apply. Shouldn't this BCP give actual recommendations on how to manage this (preferably without full page redirections, because those destroy the state of a SPA), rather than simply forbidding refresh tokens? 9.7. Content-Security Policy A very important measure to secure your browser based application is a strong CSP, but it is also very hard to do correctly. The current advise is a bit broad. I think it should explicitly state the policies that should NOT be allowed (inline scripting, eval). This was already mentioned by Dominick Baier. Also, it could benefit from a few examples (correct and wrong). Best regards, Emond Papegaaij Topicus KeyHub ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
