OIPM: Access Control Method to Prevent ID/Session Token Abuse on

OpenID Connect

Junki Yuasa

, Taisho Sasada

1,2

, Christophe Kiennert

, Gregory Blanc

, Yuzo Taenaka

and Youki Kadobayashi

Graduate School of Science and Technology, Nara Institute Science and Technology, Ikoma 630-0192, Japan

Research Fellow (PD) of the Japan Society for the Promotion of Science, Tokyo 102-0083, Japan

SAMOVAR, T

ecom SudParis, Institut Polytechnique de Paris, 91120 Palaiseau, France

Keywords:

Access Control, User Authenticity, Single Sign-On, OpenID Connect, FIDO, Session Hijacking.

Abstract:

In recent years, the adoption of Single Sign-On (SSO) has been progressing to reduce the burden of user ac-

count management in web services. In web services using OpenID Connect, a primary SSO protocol, the user

is authenticated using an ID Token (IDT) issued by the identity provider. The Session Token (ST) generated

after authentication is often used to authenticate subsequent requests. However, attackers can acquire victims’

IDT/ST through Cross-Site Scripting (XSS) or malicious browser extensions, enabling them to hijack sessions

and impersonate victims. Related studies have proposed countermeasures against impersonation attacks using

IDT/ST. Still, their effectiveness is limited against user-level malware (e.g., malicious browser extensions),

making it impossible to prevent impersonation entirely. This study proposes OIPM (OpenID Connect Imper-

sonation Prevention Mechanism) as a countermeasure to address the issue of impersonation using IDT/ST.

Speciﬁcally, a unique private key is generated during user registration using FIDO, a passwordless authenti-

cation technology. This private key’s signature is veriﬁed during authentication to prevent impersonation, and

a temporary private key generated at authentication is used for subsequent request veriﬁcation. Additionally,

post-authentication high-conﬁdentiality operations require user veriﬁcation through FIDO-based gestures such

as ﬁngerprints to ensure security against user-level malware.

1 INTRODUCTION

Single Sign-On (SSO) has become widespread to re-

duce the burden of account management in recent

years. OpenID Connect is one of the SSO protocols

and is supported by large companies like Google and

Microsoft. With OpenID Connect, users only need

to log in once to the Identity Provider (IdP) such as

Google or Microsoft; the IdP provides the user’s au-

thentication and attributes information to other web

services, the Relying Party (RP). This enables users

to utilize multiple services with a single account.

In OpenID Connect, the IdP issues ID To-

ken (IDT) that contains user attributes post-

authentication. After verifying the IDT’s authentic-

ity, the RP authenticates the user and issues a Ses-

sion Token (ST) to manage the session. However, at-

tackers can acquire users’ credentials via phishing at

the IdP or obtain IDT/ST through XSS and user-level

malware (e.g., malicious browser extensions). This

allows them to impersonate users, access sensitive in-

formation, or conduct ﬁnancial transactions.

Openpubkey (Heilman et al., 2023) has proposed

countermeasures against impersonation attacks using

IDT. These attacks can stem from vulnerabilities like

XSS or local threats like user-level malware. Open-

pubkey links a public key to the IDT for signature

veriﬁcation to prevent unauthorized use. However,

this approach falls short against local threats where

malicious browser extensions could access and use a

victim’s private key to forge a valid signature.

Studies have proposed methods beyond OpenID

Connect to combat session hijacking by protecting ST

from remote attacks (Nikiforakis et al., 2011; Tang

et al., 2011; Bugliesi et al., 2015). However, their

effectiveness is limited against user-level malware.

Moreover, some approaches prevent impersonation

by signing ST with secret information (Johns et al.,

2012; Dacosta et al., 2012; De Ryck et al., 2015).

However, these approaches also fall short of user-

level malware that can access secrets and forge valid

signatures.

This study addresses the stolen IDT and ST threats

from XSS and user-level malware. We introduce an

OIPM that ensures user authenticity by requiring sig-

674

Yuasa, J., Sasada, T., Kiennert, C., Blanc, G., Taenaka, Y. and Kadobayashi, Y.

OIPM: Access Control Method to Prevent ID/Session Token Abuse on OpenID Connect.

DOI: 10.5220/0012757900003767

Paper published under CC license (CC BY-NC-ND 4.0)

In Proceedings of the 21st International Conference on Security and Cryptography (SECRYPT 2024), pages 674-679

ISBN: 978-989-758-709-2; ISSN: 2184-7711

nature veriﬁcation with a private key created dur-

ing account setup. This mechanism veriﬁes email

ownership and employs Fast Identity Online (FIDO)

for robust identity conﬁrmation throughout the au-

thentication processes. It also generates an unpre-

dictable ‘secret‘ during authentication and is used for

continuous hash value veriﬁcation and IP and de-

vice checks. To combat local threats, our method

includes a re-authentication feature for web applica-

tions, which protects sensitive operations like access-

ing conﬁdential data or conducting critical transac-

tions. Our OIPM is designed for websites with SSO

that demand high reliability.

2 OpenID CONNECT

OpenID Connect

, based on OAuth 2.0

, is an authen-

tication protocol enabling ID federation across appli-

cations. It involves interactions among three entities:

the IdP, the RP, and the user. The IdP authenticates the

user and shares attribute information with the RP, pro-

viding services based on this authentication. OpenID

Connect supports three authentication ﬂows: Autho-

rization Code Flow, Implicit Flow, and Hybrid Flow.

This study focuses on the Implicit Flow

, where the

IDT is directly received through the browser. This

ﬂow is particularly used for simple login implemen-

tations without managing RP credentials, making it

popular among RPs.

Fig. 1 shows the targeted use case using Implicit

Flow. First, the user starts the authentication by click-

ing a login button in the browser (Process 1). The

RP then requests authentication via browser redirec-

tion to the IdP (Process 2). The IdP presents a login

page where the user inputs credentials and a consent

page for user approval to share attribute information

with the RP (Process 3). Upon consent, the IdP issues

an IDT containing the user’s identiﬁer ‘sub,‘ the RP’s

identiﬁer ‘aud,‘ and the user’s email ‘email‘ and sends

it back via redirection (Process 4). Since processes 1

to 4 are Implicit Flow steps, the rest of the use case

will be explained in Section 3.1.

3 PROBLEM DEFINITION

In this section, we describe the OpenID Connect use

case and threat model targeted in this study and ad-

https://openid.net/specs/openid-connect-core-1 0.

html

https://datatracker.ietf.org/doc/html/rfc6749

Note that while the Implicit Flow is deprecated in

OAuth 2.0, it is not deprecated in OpenID Connect.

Figure 1: The Target Use Case of This Study.

dress the authenticity problems upon authentication

and post-authentication in RP. We also deﬁne access

patterns by attackers when user authenticity cannot be

guaranteed.

3.1 Target Use Case

Fig. 1 illustrates this study’s OpenID Connect use

case, focusing on user registration and authentication

via SSO. During SSO, the IdP veriﬁes the user’s cre-

dentials (e.g., email address, password). The user

then receives an IDT through the browser and for-

wards it to the RP for authentication (Processes 5 and

6). After authentication, an ST to identify the user’s

session is issued and returned to the user (Process 7).

The ST is included in a cookie for subsequent RP

requests to facilitate session-related data processing

(Processes 8 and 9).

3.2 Threat Model

This study assumes a threat model based on the web

attacker model. The threat model includes three

threats: a phishing threat, an XSS threat, and a user-

level malware threat. Each threat operates distinctly

without one being a prerequisite for another.

Phishing Threat: Attackers can lure victims to their

hosted websites (e.g., attacker.com) and steal their

credentials by having them enter the information on

the website.

XSS Threat: Attackers can also exploit XSS vul-

nerabilities on the RP, executing arbitrary JavaScript

on the victim’s browser. This allows them to by-

pass browser-based XSS countermeasures (e.g., the

HttpOnly attribute for cookies, Content Security Pol-

icy) and steal IDT/ST.

User-level Malware Threat: We assume attackers

can infect the client with malware to consider ro-

bust countermeasures against compromising user de-

vices. We speciﬁcally consider malware with only

user-level access, such as malicious browser exten-

sions, excluding malware with root-level access. We

OIPM: Access Control Method to Prevent ID/Session Token Abuse on OpenID Connect

675

assume that the OS protection mechanisms are fully

operational against user-level malware. This threat

is realistic due to numerous malicious browser exten-

sions installed on many users’ devices in the Chrome

web store. Our threat model does not include attacks

against the FIDO2 protocol itself, assuming that it is

secure. Users are presumed to use physical authen-

ticators (not virtual) certiﬁed at L2 or above by the

FIDO Alliance.

Finally, we do not assume that parties other than

the user in OpenID Connect (RP, IdP) can be compro-

mised. For instance, attackers cannot compromise the

RP to alter the authenticity veriﬁcation results or the

IdP to steal the secret keys for signing IDT.

3.3 Authenticity Problems

Authentication in RP: The IDT includes a nonce to

mitigate unauthorized acquisition and prevent replay

attacks. However, if an attacker acquires a valid, un-

used IDT, e.g., using malicious browser extensions,

they can impersonate the user by submitting it to an

RP that recognizes the RP identiﬁer (aud). Addition-

ally, attackers may acquire a victim’s credentials at

the IdP through phishing, allowing them to obtain a

new IDT. By submitting these tokens to the RP, at-

tackers can compromise user authenticity and log in

as the victim.

Post-Authentication in RP: STs are managed as

cookies in browser storage. Attackers can exploit the

XSS vulnerability on the RP to execute JavaScript in

a victim’s browser or use malicious browser exten-

sions to acquire the ST from the victim’s browser.

So, attackers can use the stolen ST to perform post-

authentication operations as legitimate users.

Potential Access Patterns: During authentication in

the RP, attacker access patterns with IDT include:

(IT-1) stealing and submitting the IDT; (IT-2) using

stolen credentials to obtain and submit a new IDT

from the IdP. Both scenarios allow requests from ei-

ther the attacker’s or the victim’s browser.

In the post-authentication phase, attacker access

patterns with ST are: (ST-1) stealing the ST via XSS

and making requests from the attacker’s browser;

(ST-2) using the ST from a compromised victim’s

browser due to XSS or browser hijacking.

4 RELATED WORKS

Studies on impersonation attacks using IDT (Mainka

et al., 2017) show that attackers can tamper with

or forge tokens using a victim’s identiﬁer. This at-

tack can be detected by verifying the signature of the

Figure 2: Overview of OIPM.

IDT. However, if legitimate IDT can be stolen, the

signature value would be correct, making imperson-

ation undetectable. The Openpubkey method (Heil-

man et al., 2023) addresses this by embedding users’

public keys in IDTs for signature veriﬁcation, en-

hancing security against impersonation. It also intro-

duces the MFA-cosigner feature, which requires ad-

ditional authentication beyond the IdP, increasing se-

curity but also adding complexity. Nonetheless, mali-

cious browser extensions might still enable attackers

to forge valid signatures.

Session hijacking, where STs are stolen through

exploits like XSS or malicious browser extensions,

has led to several defensive solutions. SessionShield

(Nikiforakis et al., 2011), Zan (Tang et al., 2011),

and Cookiext (Bugliesi et al., 2015) protect STs by

managing them outside the browser or by setting se-

cure cookie attributes, though their defense against

browser extensions is limited. Alternatives like Bet-

terAuth (Johns et al., 2012), One-time cookies (Da-

costa et al., 2012), and SecSess (De Ryck et al., 2015)

enhance security by generating unique hash values for

each request using HMAC authentication, which con-

ﬁrms the possession of secret user information. One-

time cookies use TLS for secret exchange, while Bet-

terAuth and SecSess utilize Difﬁe-Hellman for secret

sharing without TLS. However, these methods cannot

prevent impersonation if malicious extensions access

the secret to forge valid hashes.

This study highlights the limitations of current de-

fenses against impersonation using IDT and session

hijacking, especially concerning local threats like ma-

licious browser extensions. We propose a new coun-

termeasure to prevent impersonation involving IDT

and ST.

SECRYPT 2024 - 21st International Conference on Security and Cryptography

676

5 OIPM DESCRIPTION

5.1 Verifying Authenticity of ID Tokens

This section proposes a method to verify user authen-

ticity during authentication. It begins with checking

the user’s IDT and verifying email ownership at reg-

istration, preventing attackers without email access

from registering. Users generate private and public

keys during registration. Based on FIDO2, signa-

ture veriﬁcation ensures security as the private key is

stored in a FIDO device that is resistant to attacks, re-

quiring a PIN or biometric veriﬁcation. FIDO2’s fea-

tures, like KHAccessToken and authenticatorClient-

PIN, are safeguarded against user-level malware, pre-

venting attackers from forging signatures(Kuchhal

et al., 2023).

Key Pair Generation During User Registration:

User registration (phase 1 in Fig. 2) involves gen-

erating a key pair, starting with the user registering

at the RP, followed by IdP authentication and receiv-

ing an IDT. The IDT is sent to the RP for valida-

tion, and the RP emails a conﬁrmation URL to the

user. Upon clicking this URL, a personal conﬁr-

mation token is validated by the RP, which then is-

sues a session-speciﬁc challenge to the authenticator

through the browser. User authenticity is conﬁrmed

by biometric or PIN veriﬁcation on the authenticator,

generating a key pair with the private key stored se-

curely in the authenticator. The public key, sent to

the RP along with the IDT, is saved for future login

authenticity veriﬁcation.

Authenticity Veriﬁcation Using Private Key at Au-

thentication: During authentication, the signature

created by the user is veriﬁed (phase 2 in Fig. 2).

Speciﬁcally, the RP uses a private key to generate a

signature that includes a random string, known as a

challenge value. This signature, along with the IDT, is

then transmitted to the RP, which uses the public key

to verify the validity of the signature. The authenticity

veriﬁcation process using a signature during authenti-

cation is detailed in Fig. 3.

The user authentication process at the RP starts

with the user logging in and receiving an IDT from

the IdP, which is then sent to the RP for veriﬁca-

tion. The RP issues a session-speciﬁc challenge to

the authenticator to prevent replay attacks and ensure

session uniqueness. The user conﬁrms their identity

through biometric or PIN authentication on the au-

thenticator, which then uses the private key to create

a signature. This signature, along with the IDT, is

sent to the RP, where the public key, provided dur-

ing registration, is used to validate the signature and

authenticate the user. Although authentication can be

Figure 3: Authenticity Veriﬁcation Using Private Key at

Authentication.

achieved solely through FIDO-based signatures, it is

crucial for SSO that RPs continuously reference and

update IdP user information for personalized expe-

riences. Therefore, transmitting the IDT alongside

FIDO-based signatures remains essential.

5.2 Verifying Authenticity of Session

Tokens

This section proposes a method for verifying user au-

thenticity in post-authentication. Speciﬁcally, when

users have been logged in, a random string (secret)

shared exclusively between the user and the RP is

generated. This allows the veriﬁcation of user authen-

ticity at the time of post-authentication to be substi-

tuted and veriﬁed through the maintenance of the se-

cret. The following explains the generation and ver-

iﬁcation method of the secret at the time of authen-

tication and describes a re-authentication method to

address the threat of secret theft.

Authenticity Veriﬁcation Using Secret at Post-

Authentication: During authentication, verifying au-

thenticity with FIDO private keys requires a ges-

ture. Requiring gestures for each post-authentication

request would hinder convenience, so we use a

shared secret between the user and RP instead. This

128-bit random string (secret) secures request au-

thenticity and resists brute-force attacks. For post-

authentication requests, the user-generated hash value

is veriﬁed (phase 3 in Fig. 2). Speciﬁcally, a hash

value is generated using a nonce value and the secret

created by the RP, and this hash value, along with the

ST, is sent to the RP. The RP then generates a hash

value using the nonce value and secret and compares

it with the received one.

After user authentication, the RP stores an unpre-

dictable secret, the user’s IP address and device de-

tails. Additionally, the RP issues a ST and returns it

with the secret. The secret is stored in non-persistent

OIPM: Access Control Method to Prevent ID/Session Token Abuse on OpenID Connect

677

Figure 4: Authenticity Veriﬁcation for Conﬁdential Re-

quests after Authentication.

in-memory storage using JavaScript closures

. Since

variables deﬁned within the scope of a function can-

not be referenced from outside the scope, the secret

cannot be referenced from external JavaScript pro-

vided via XSS. Users also obtain a nonce from the RP

to prevent hash reuse. A JavaScript program on the

browser combines this secret and nonce to generate a

hash. The RP veriﬁes the user by comparing this hash

with its generated one and checks the request’s IP and

device details, denying access to attackers even with

a valid ST. Access is granted only if both veriﬁcations

pass. In addition, if a user’s IP changes, they must log

in again.

Re-authentication Methods to Address Secret

Theft Threats: The post-authentication veriﬁcation

process, outlined previously, checks IP and device in-

formation to mitigate impersonation from stolen se-

crets or hashes. However, attackers could still capture

the secret through malicious browser extensions that

access communication logs. To address this, sensitive

actions like accessing conﬁdential data or making ﬁ-

nancial transactions require FIDO re-authentication,

as phase 4 of Fig. 2 illustrates. This involves local au-

thentication on the user’s device with FIDO and veri-

ﬁcation of hash values, IP, and device info by the RP,

including signature checks using a public key.

6 EVALUATION

Implementation Method: The experimental setup

uses a Ubuntu 22.04 LTS server with a 6-core pro-

cessor and employs Docker and Docker Compose for

virtualization and container management. The OIPM

is built with Node.js, Express as the web server, and

MongoDB as the database, with its code hosted on

https://developer.mozilla.org/en-US/docs/Web/

JavaScript/Closures

Table 1: Control Results for Each Access Pattern.

User Information Request Origin Result

Victim

Credential Victim Allowed

ST, Secret Victim Allowed

Attacker

Credential Attacker Denied

Credential Victim Denied

IDT Attacker Denied

IDT Victim Denied

ST, Secret Attacker Denied

ST, Secret Victim Allowed

ST, Hash Attacker Denied

ST, Hash Victim Denied

ST, Secret Victim Denied

GitHub

. We simulated the attacker, victim, RP, and

IdP as containers on the same network for access pat-

tern evaluation.

6.1 Access Pattern Evaluation

This study evaluates OIPM’s response to legitimate

user and attacker-induced access patterns, as outlined

in Section 3.3. Table 1 shows control outcomes

for victims and attackers during RP login and post-

if the ST and secret are transmitted from the vic-

tim’s browser. However, access can be safeguarded

against malicious browser extensions by mandating

re-authentication using FIDO for sensitive operations.

These ﬁndings demonstrate OIPM’s effectiveness in

preventing impersonation at both the authentication

and post-authentication stages.

6.2 Performance Evaluation and

Discussion

This study measures OIPM’s impact on system per-

formance by analyzing response times and computa-

tional resource usage before and after deployment.

Response Time: We assess the response time for au-

thentication and post-authentication requests to the

RP’s server using the PlayWright browser automa-

tion tool, executing 100 requests at 500-millisecond

intervals. Pre-OIPM authentication requests averaged

550 milliseconds, with a post-deployment increase of

100 milliseconds. Post-authentication requests went

from a 50- to a 5-millisecond delay, and conﬁdential

requests needing FIDO re-authentication experienced

an additional 10-millisecond delay (Fig. 5).

Computational Resource Load: We used Docker

stats to monitor the resource usage of Docker con-

tainers for the RP, measuring average memory and

https://github.com/oidc-access-control/OIPM

SECRYPT 2024 - 21st International Conference on Security and Cryptography

678

Figure 5: Response Time. Figure 6: CPU Usage Rate. Figure 7: Memory Usage.

CPU utilization under 100 authentication and post-

authentication requests before and after OIPM’s im-

plementation. Data on memory and CPU usage were

collected at one-second intervals, with outliers re-

moved using z-score for data points within +/- 3

standard deviations, as shown in Fig. 6 and Fig.

7. Post-implementation, CPU utilization doubled

for authentication requests and quadrupled for post-

authentication, with a ﬁve-fold increase for conﬁden-

tial requests. Memory usage remained stable, with a

1.5 times increase only for conﬁdential requests.

Discussion: Verifying email ownership in OIPM is

critical to prevent attackers from associating their

keys with a victim’s ID, a feature not present in stan-

dard SSO. It is important to create identity veriﬁcation

methods that maintain user convenience. Addition-

ally, OIPM’s requirement for FIDO implementation

faces challenges due to its low website adoption rate.

Future studies should also consider the costs of adopt-

ing FIDO.

7 CONCLUSION

This proposal attempted to ensure user authenticity

in OpenID Connect at the RP. Our proposed OIPM

method leverages FIDO private keys for signature ver-

iﬁcation and secret information for hash veriﬁcation,

protecting against user-level malware. The method

shows access control can be managed effectively with

little system impact. Future efforts will aim to create

an easy identity veriﬁcation process and assess FIDO

costs.

ACKNOWLEDGEMENTS

This work was partly supported by JSPS KAKENHI

Grant Number JP24K03045.

REFERENCES

Bugliesi, M., Calzavara, S., Focardi, R., and Khan, W.

(2015). Cookiext: Patching the browser against ses-

sion hijacking attacks. Journal of Computer Security,

23(4):509–537.

Dacosta, I., Chakradeo, S., Ahamad, M., and Traynor, P.

(2012). One-time cookies: Preventing session hijack-

ing attacks with stateless authentication tokens. ACM

Transactions on Internet Technology, 12(1):1–24.

De Ryck, P., Desmet, L., Piessens, F., and Joosen, W.

(2015). Secsess: Keeping your session tucked away in

your browser. In Proceedings of the 30th Annual ACM

Symposium on Applied Computing, pages 2171–2176.

Heilman, E., Mugnier, L., Filippidis, A., Goldberg, S., Lip-

man, S., Marcus, Y., Milano, M., Premkumar, S.,

and Unrein, C. (2023). Openpubkey: Augmenting

openid connect with user held signing keys. Cryp-

tology ePrint Archive.

Johns, M., Lekies, S., Braun, B., and Flesch, B. (2012).

Betterauth: web authentication revisited. In Proceed-

ings of the 28th Annual Computer Security Applica-

tions Conference, pages 169–178.

Kuchhal, D., Saad, M., Oest, A., and Li, F. (2023). Evalu-

ating the security posture of real-world ﬁdo2 deploy-

ments. In Proceedings of the 2023 ACM SIGSAC Con-

ference on Computer and Communications Security,

pages 2381–2395.

Mainka, C., Mladenov, V., Schwenk, J., and Wich, T.

(2017). Sok: single sign-on security—an evaluation

of openid connect. In Proceedings of the 2017 IEEE

European Symposium on Security and Privacy, pages

251–266.

Nikiforakis, N., Meert, W., Younan, Y., Johns, M., and

Joosen, W. (2011). Sessionshield: Lightweight pro-

tection against session hijacking. In Proceedings of

the 3rd International Symposium on Engineering Se-

cure Software and Systems, pages 87–100.

Tang, S., Dautenhahn, N., and King, S. T. (2011). Fortifying

web-based applications automatically. In Proceedings

of the 18th ACM conference on Computer and com-

munications security, pages 615–626.

OIPM: Access Control Method to Prevent ID/Session Token Abuse on OpenID Connect

679