When used simply for authentication, receiving and validating an ID token is sufficient to open an authenticated session at the RP, hence the current default in v0.1.0:
- response type
"id_token" (implicit flow) and response mode "form_post" if the OP supports both
- authorization code flow otherwise
An intercepted ID token could be replayed (if JTIRegister is not used to prevent it) but how could an ID token be intercepted in such a case?
A common scenario is when the user has installed a malicious extension. However, browser extensions can access all cookies and replaying an ID token wouldn't have an interest for the attacker already in possession of a stolen authentication cookie, at the RP or at the OP.
When used simply for authentication, receiving and validating an ID token is sufficient to open an authenticated session at the RP, hence the current default in v0.1.0:
"id_token"(implicit flow) and response mode"form_post"if the OP supports bothAn intercepted ID token could be replayed (if JTIRegister is not used to prevent it) but how could an ID token be intercepted in such a case?
A common scenario is when the user has installed a malicious extension. However, browser extensions can access all cookies and replaying an ID token wouldn't have an interest for the attacker already in possession of a stolen authentication cookie, at the RP or at the OP.