I think of this as somewhat similar to:
a) a grant type where a cookie grant is exchanged at an "RP token
endpoint" for an associated access and refresh token; the protocol between
SPA and the API to do so would benefit from standardization e.g. into SDKs
and server side frameworks
b) an "RP token
Adam Roach has entered the following ballot position for
draft-ietf-oauth-token-exchange-16: Discuss
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to htt
All important points. I'm not sure it affects whether refresh_tokens
should be bound to the authenticated session or not. If using a
continuous authentication model, it just means that as long as the AS/OP
believes the authentication session is valid, the refresh_token will
also continue to be
> On Nov 20, 2018, at 1:37 PM, Aaron Parecki wrote:
>
> The new section on refresh tokens is great! I have a couple
> questions/comments about some of the details.
>
> Authorization servers may revoke refresh tokens automatically in case
> of a security event, such as:
> o logout at the auth
Thanks for the additional section on refresh_tokens. Some additional
recommendations...
1. By default refresh_tokens are bound to the user's authenticated
session. When the authenticated session expires or is terminated
(whether by the user or for some other reason) the refresh_tokenis
implic
Post response works OK for server based clients. I don't think POST works
for single page applications.
Basically that would be something more like postmessage between two JS
apps.
Postmessage also has security issues passing a access token and leaking.
Perhaps someone more familiar with SPA ca
+1
This model is useful and should be documented in its own right. Once
documented it could possibly be referenced in the BCP.
On 11/9/18 1:44 PM, David Waite wrote:
Hi Hans, I hope it is acceptable to reply to your message on-list.
Others could correct me if I am wrong, but I believe the pu
Hi Mike,
The Form Post Response Mode keeps the access_token out of the URL, but
it doesn't prevent the token from traversing through the browser. So a
man-in-the-browser attack may be able to intercept the values. It should
help with leakage in logs.
Thanks,
George
On 11/20/18 4:00 PM, Mike
Hi Aaron,
We don't issue refresh_tokens for any implicit flow. So if a browser
based app were to use the code flow, we would issue a refresh_token.
Restricting which clients can receive refresh_tokens (or based on some
other policy) is not a significant addition. However, for most browser
app
On Tue, Nov 20, 2018, 2:56 PM Send OAuth mailing list submissions to
> oauth@ietf.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://www.ietf.org/mailman/listinfo/oauth
> or, via email, send a message with subject or body 'help' to
> oauth-requ...@i
Next question – doesn’t using the Form Post Response Mode
https://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html mitigate the
threats you’re describing below John? If so, I believe the Security Topics
draft should say this.
I believe we owe it to readers to present the complete pic
Hi George,
Reading this description, am I understanding correctly that you *always*
return a refresh token to every client? Are there any situations in which a
refresh token would not be returned? Specifically I'm wondering about how
this applies to browser-based apps using the authorization code
Hi Torsten,
This is the module I much prefer. By default all refresh_tokens are
bound to the user's authenticated session. When the authentication
session is terminated, the refresh_tokens are invalidated. If a client
wants to get a refresh_token that is NOT bound to an authentication
session
email
On Tue, Nov 20, 2018, 1:37 PM Send OAuth mailing list submissions to
> oauth@ietf.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://www.ietf.org/mailman/listinfo/oauth
> or, via email, send a message with subject or body 'help' to
> oauth-re
The new section on refresh tokens is great! I have a couple
questions/comments about some of the details.
Authorization servers may revoke refresh tokens automatically in case
> of a security event, such as:
> o logout at the authorization server
This doesn't sound like the desired behavior for
In regards to the comment on section 4.1, it depends on the
authorization policy and the deployment architecture. I don't believe
there is a single solution that will work with all deployments.
It may be worth calling out that exposure of the entire delegation chain
can leak information and th
Agreed with 4. Since the security BCP is deprecating the implicit flow, it
seems like it's not worth the effort to try to come up with a solution for
this when the security implications of doing this aren't clear yet either.
Aaron Parecki
aaronparecki.com
On Tue, Nov 20, 2018 at 11:36 AM Tor
Jari, thanks for your review. Brian, thanks for your response. I flagged the
issue Jari raises below in my DISCUSS ballot — it’s not clear to me why there
aren’t normative requirements around confidentiality as there are in the JWT
spec and the OAuth 2.0 spec.
Thanks,
Alissa
> On Aug 10, 2018,
Alissa Cooper has entered the following ballot position for
draft-ietf-oauth-token-exchange-16: Discuss
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to
Hi all,
please find some thoughts about refresh token protection in the new revision of
the Security BCP
https://tools.ietf.org/html/draft-ietf-oauth-security-topics-10#section-3.12
Feedback welcome!
kind regards,
Torsten.
> Am 19.11.2018 um 11:33 schrieb Jim Manico :
>
> I want to +1 this
I opt for (4) - Remove support/description of binding of access tokens issued
from the authorization endpoint
I think the potential solution we worked out (slide 6) is to complex and the
security implications of the redirect via the resource servers are still
unclear.
> Am 18.11.2018 um 13:32
Hi all,
the new revision contains the following changes:
* added section on refresh tokens
* additional justifications for recommendation for code
* refactored 2.1 in order to distinguish CSRF, authz response replay and mix-up
(based on feedback by Joseph Heenan)
* added requirement to authent
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol WG of the IETF.
Title : OAuth 2.0 Security Best Current Practice
Authors : Torsten Lodderstedt
J
Yes the at_hash protects the client from accepting an injected AT.
Unfortunately it doesn't do anything to protect against leakage in logs
or redirects.
So without the AT using some sort of POP mechanism it is hard to say
sending it in a redirect is a good security practice.
John B.
On 11/
On Tue, Nov 20, 2018, 6:25 AM Send OAuth mailing list submissions to
> oauth@ietf.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://www.ietf.org/mailman/listinfo/oauth
> or, via email, send a message with subject or body 'help' to
> oauth-requ...@i
I think the draft should elaborate more on what it means by “token replay” in
section 2.2 and how the proposal to use sender-constrained tokens prevents it.
As far as I can tell, of the 4 methods presented in section 3.8.1.2, only jpop
signed requests actually includes any specific countermeasur
Hi all,
a recent query about expiring client credentials (secrets) got me thinking
about client_secret_expires_at client metadata from RFC 7591 used also in
7592 as well as OpenID Connect Dynamic Client Registration 1.0
*What does expired client secret (in the sense of client_secret_expires_at
wi
27 matches
Mail list logo
