Good points.
Also, while it may be off-topic, I do see values in implicit flows. In some
cases, such as when the AS is inside the firewall or on a localhost (e.g.,
smartphone), “code flow” is not possible as the client cannot reach the AS
directly. Banning implicit (and thus “token id_token”
>> The AS can bind the lifetime of the refresh tokens to the session lifetime,
>>i.e. automatically revoke it on logout.
> Yea, I saw your other email asking about refresh token revocation relating to
> session management. Obviously for certain clients, this won't make sense, but
> for
> Could you please expand on what you are achieving with replacing the URL
>using the history API? Removing the token from the browser's history, or any
>protection beyond that?
Just this block of code which would be run on the redirect_uri page loaded in
the client (after id_token/token
> Going from Implicit to Code deals with the problem of sending RT in the URL,
>which I agree is a plus. Is there anything else in a way of an improvement?
As far as I can tell, that's the only additional security feature (beyond what
we already use for mitigations today) that code flow adds.
Thanks Evan.
This seems like a good start and I'll plan to work to incorporate the
proposal in some/similar form into the next revision of the document.
Comments, clarifications, etc. from the WG are also always welcome too in
the meantime. Or from the AD, who also suggested allowing for the use
