# Resilient Risk based Adaptive Authentication and Authorization (RAD-AA)
Framework

Jaimandeep Singh  School of Cyber Security & Digital Forensics
National Forensic Sciences University
Gujarat, India
<EMAIL_ADDRESS>Chintan Patel  Dept. of Comp. Sci.
The University of Sheffield
Sheffield, UK
<EMAIL_ADDRESS>Naveen Kumar Chaudhary  School of Cyber Security &
Digital Forensics
National Forensic Sciences University
Gujarat, India
<EMAIL_ADDRESS>
###### Abstract

In recent cyber attacks, credential theft has emerged as one of the primary
vectors of gaining entry into the system. Once attacker(s) have a foothold in
the system, they use various techniques including token manipulation to
elevate the privileges and access protected resources. This makes
authentication and token based authorization a critical component for a secure
and resilient cyber system. In this paper we discuss the design considerations
for such a secure and resilient authentication and authorization framework
capable of self-adapting based on the risk scores and trust profiles. We
compare this design with the existing standards such as OAuth 2.0, OpenID
Connect and SAML 2.0. We then study popular threat models such as STRIDE and
PASTA and summarize the resilience of the proposed architecture against common
and relevant threat vectors. We call this framework as Resilient Risk based
Adaptive Authentication and Authorization (RAD-AA). The proposed framework
excessively increases the cost for an adversary to launch and sustain any
cyber attack and provides much-needed strength to critical infrastructure. We
also discuss the machine learning (ML) approach for the adaptive engine to
accurately classify transactions and arrive at risk scores.

###### Index Terms:

Federated Authentication, Delegated Authorization, Cyber Resilience, Adaptive
Engine, Identity Management Systems, Threat Models, secure architecture and
framework, OAuth 2.0, OpenID Connect, SAML 2.0

##  I Introduction

As per the July-2022 report by IBM [1], one of the most frequent reasons for a
data breach is using stolen or compromised credentials. The primary attack
vector in 19% of incidents was stolen or exposed credentials. Stolen
credentials can also lead to significant damage to the complete ecosystem as
was seen in the case of ransomware attack on the colonial pipeline system in
the United States [2]. Nowadays hackers do not break into the system but log
into it, making the authentication and authorization systems a core design
feature of any security architecture. With the help of authentication, we
decide who can enter and with the help of authorization, we decide up to what
level he or she can access the system.

Risk and trust based adaptive approach for authentication and authorization
(RAD-AA) is required for a secure and resilient cyber system. Stringent
security requirements are known to increase the friction in user experience.
The adaptive approach also helps in reducing this friction by adjusting
security requirements based on the context and the flow. In a traditional
authentication system the credentials of a user are verified in a sequential
manner by employing various means such as user name, password, one-time
password or biometrics. However, in RAD-AA approach the credential
verification requirements are dependent on the risk score of the transactions
and the trust relationship between different entities of the ecosystem.
Example: For a high risk transaction, the system may ask for MFA such as
approving the notification received over the device or answer the security
questions, while at low risk, the system may continue based on just user name
and password. RAD-AA based framework decides risk score based on the user’s or
system’s state. For example: If a user tries to log in from a different
geographic location, device, vulnerable application, or browser, then the
system increases the risk score for the transaction. Sometimes, if there is an
attack on the complete critical infrastructure of the organization, then the
RAD-AA framework-based system increases the risk score for the complete system
and expects that each user must pass through the high-security verification.
Similarly, for access control or authorization, based on risk score, the RAD-
AA system can upgrade, degrade or revoke the rights given to a user or group
of users. In this paper, we propose a novel Resilient Risk based Adaptive
Authentication and Authorization (RAD-AA) framework that is attack-resilient
and highly adaptive to the underlying risk factors.

The remainder of the paper is as follows: Section II presents related work. In
this section, we discuss the existing features of OAuth 2.0, OpenID connect,
and SAML 2.0 standards. The most common threat models are discussed in section
III followed by design considerations for RAD-AA framework in section IV. The
proposed architecture including and threat vector vs RAD-AA resilience matrix
is discussed in section V. This section also includes discussion on ML based
approach for adaptive engine followed by conclusion and future work in section
VI.

##  II Related Work

There are several authentication and authorization frameworks available and
adopted by the industries. OAuth 2.0 [3] protocol provides authorization for
mobile, web and desktop applications and other smart devices. The OAuth 2.0
framework consists of four essential components: resource owner, resource
server, client, authorization framework. The RFC 6819 [4] defines the attacker
capabilities and threat model for the OAuth 2.0 standard such as obtaining
client secrets, obtaining refresh tokens, obtaining access tokens, phishing of
end-user credential, open redirectors on client, password phishing.

Since, OAuth 2.0 provides only authorization framework, OpenID connect [5]
integrates an identity layer to it and enables authentication of the end user
for the client side applications. An OpenID connect permits all types of
clients such as JSClient, web client, and mobile client.

An open XML-based SAML 2.0 (standard called Security Assertion Markup
Language) [6, 7] is frequently used to exchange authentication and
authorization (AA) data amongst federated organisations. With the help of SAML
2.0, the end user can log into multiple web-applications using the same
credentials. SAML 2.0 enables single sign-on (SSO) facilities to access
several independent applications with the help of an identity provider. The
SAML 2.0 provides numerous advantages, such as users need not remember
multiple user names and passwords, which also reduces access time, cost
reduction, and labour cost reduction.

There are other several authentication protocols such as LDAP (Lightweight
Directory Access Protocol), Kerberos, RADIUS but considering industry adoption
and need of resilient adaptive authentication and authorization framework, we
have compared the proposed framework with OAuth 2.0, OpenID connect, and SAML
2.0 in section IV.

##  III Threat Models

This section presents widely used threat models which are relevant to our
proposed framework. Threat modelling is the security procedure used to
identify, classify, and examine potential risks. Threat modelling can be
carried out either proactively during design and development or resolutely
after a product has been released. In either situation, the method identifies
the possible harm, the likelihood that it will happen, the importance of the
issue, and the ways to remove or lessen the threat. Threats and
vulnerabilities are frequently paired in order to find the risk to an
organization or a system.

In this paper, we have adopted the relevant portions of the existing threat
models and tailored them based on the characteristics of different entities of
the framework and their interactions with internal and external entities. The
first threat model we have considered is STRIDE, developed by Microsoft [8].
The STRIDE model discusses six different types of threats. The first threat is
Spoofing where the adversary spoofs user identity and tries to access the
resources with secure authentication as a desirable property. The next threat
is Tampering where an adversary tampers the messages communicated over the
open channel, and the desired property is integrity. The third threat is
repudiation where attacker performs some illegal activities and denies
performing those activities. The desirable property to tackle this threat is
non-repudiation, achievable using secure signature methods. The next threat is
information disclosure where the adversary tries to read or access the secret
information. The desirable property is the confidentiality that can be
achieved using secure encryption/decryption system. The next threat is denial
of service attack where an adversary tries to prevent an end-user from
accessing services where the desirable property is availability that is
achieved through intrusion detection and intrusion prevention system.
According to the STRIDE threat model, the last threat is elevation of
privilege where an attacker is either an insider or somehow became the trusted
insider with the high privilege to destroy the system. In this paper we
consider a number of threats from the STRIDE model such as spoofing identity
and tempering.

The PASTA (Process for Attack Simulation and Threat Analysis) is a risk-
centric threat modelling technique that incorporates risk analysis and context
into the complete security of critical infrastructure from the start [9]. The
PASTA allows threat modelling linearly through the interdependent seven
stages. In the first stage, PASTA defines the objectives for risk analysis and
provides well-defined business objectives and analysis reports. In stage two,
PASTA defines the technical scope and tries to understand possible attack
surface components and provides a detailed technical report on all attack
surface components. In the third stage, PASTA performs application
decomposition and analysis and provides a data-flow diagram, interfaces list
with trust level, asset list, and access control matrix. In the fourth stage,
PASTA performs threat analysis and generates a list of threat agents, attack
vectors, incident event reports. In stage five, it performs vulnerability
assessments and provides scoring based on CVSS (Common Vulnerability Scoring
System). In stage six, PASTA performs attack modelling and simulation of
various well-known threats. As an outcome of stage six, it provides attack
trees and possible attack paths. In the last (seventh) stage, it performs risk
analysis and management where it outcomes risk profile, risk mitigation
strategy, and threat matrix. We have considered the PASTA framework where ever
required during framework design.

##  IV Proposed design considerations for RAD-AA Framework

In this paper we propose a Risk based Adaptive Authentication and
Authorization (RAD-AA) framework which is secure by design and excessively
increases the cost for the attacker. The design considerations include
adaptive ecosystem which is capable of modifying the security requirements and
the access rights to the protected resources based on the risk score of the
transactions and interactions between different entities of the ecosystem.

The adaptive design enables the framework to anticipate the attack. In case of
a breach, the adaptive design is able to withstand and constraint the level of
damage by revoking or restricting the access rights granted or by de-
authenticating already authenticated users or increasing the security
requirements of the transactions. The design considerations of RAD-AA are
given below:

  * •

Adaptive Engine for Cyber Resilience. The authentication and authorisation
transactions and trust level between different entities in the ecosystem
should be able to adapt based on the risk score such as Geo-location,
impossible travel, IP reputation, and device information. The system should be
able to enhance, reduce or completely revoke the entry into the ecosystem or
access to the protected resources based on the risk score.

  * •

Federated Authentication. It is a system in which two parties trust each other
to authenticate the users and authorize access to resources owned by them. In
a Federated Authentication or Identity management system the identity of a
user in one system is linked with multiple identity management systems. It
extends beyond a single organization wherein multiple organizations can agree
to share the identity information and join the federation. Once the users’
login into their organizations, they can use this federated identity to access
resources in any other organization within the federation.

  * •

Delegated Authorization. A delegated authorization system can delegate access
rights to the services or processes in the form of assertions or claims.
Examples include end-user authorization delegation to a web or native
application.

  * •

Decoupling Authentication and Authorization. Decoupled authentication and
authorization systems allow for modularity and provide necessary interfaces to
replace one system with another.

  * •

Confidentiality and Non-repudiation of claims. The confidentiality will ensure
that the contents of the claims are not revealed to unauthorized parties. Non-
repudiation will assure the recipient that it is coming from the identified
sender and that the data integrity is assured.

  * •

Audience Binding. The primary aim of binding the token to the audience or the
client to which it is issued is to prevent unauthorized entities from using
the leaked or stolen tokens. The token, when issued, is bound to a public key
of the audience or the client to which it is issued. The client now needs the
corresponding private key to use the token further. This will protect against
the token’s misuse by unauthorized parties that do not possess the private
key. It provides an added assurance to the receiver that such a claim token
has been sent by the sender authorized to use it.

  * •

Trust relationships. The system should be capable of establishing trust
relationships between different entities of the ecosystem. The trust
relationship will also depend on how the two entities identify each other and
what is the relationship between the entities. The risk score of the client
applications can be taken into consideration while deciding the trust
relationship level.

  * •

Propagation of identity and claims between different ecosystems. The requested
resource or a subset of the resource may be required to be fetched from a
different ecosystem. The necessitates the propagation of identity and claims
across different ecosystems. When transitioning from one ecosystem to another,
properties of confidentiality, non-repudiation, limiting the information
contained in the claim and assurance of use by the authorized sender should be
maintained.

  * •

Time-limited Validity and Revoking issued claims. The lifetime of the issued
tokens should be limited to avoid misuse of the stolen tokens [3]. The ability
to revoke the tokens should be in-built into the design.

  * •

Support for REST API architecture. Most of the developers have now moved from
WS-* to REST as conceptualized by Fielding in his seminal PhD dissertation
[10] and stateless APIs [11]. The system design should therefore support the
REST API architecture. The REST can simply be described as HTTP commands
pushing JSON packets over the network as defined in RFC 8259 [12].

Table I presents comparison of the proposed framework with the existing
standards.

TABLE I: Comparison of existing standards with proposed design considerations
of RAD-AA

Design Considerations |  OAuth 2.0 [3] |  OpenID Connect [5] |  SAML 2.0 [6] |  Proposed Framework
---|---|---|---|---
Authentication |  NO |  YES |  YES |  YES
Adaptive Engine for Cyber Resilience |  NO |  NO |  NO |  YES
Federated Authentication |  NO |  SSO Only |  SSO Only |  YES
Delegated Authorization |  YES |  YES |  YES |  YES
Decoupling Authentication and Authorization |  YES |  YES |  YES |  YES
Out of the box support for Confidentiality and Non-repudiation of claims |  NO |  NO |  NO |  YES
Audience Binding |  NO |  NO |  NO |  YES
Trust Relationships |  NO |  NO |  NO |  YES
Time limited validity of claims |  YES |  YES |  YES |  YES
Ability to revoke issued tokens |  NO |  NO |  NO |  YES
Support for REST API architecture |  YES |  YES |  YES |  YES
Extensible to ML Based Classification |  NO |  NO |  NO |  YES

##  V Proposed Architecture and threat vector vs RAD-AA Resilience matrix

###  V-A Introduction

In this research paper we have proposed a resilient architecture based on the
various existing standards [3][6] [5][12][13], threat considerations [4], best
current practices [14][15] and augmented features of OAuth 2.0 [16]. The
architecture, entities, protocol flow and their interactions is given at
Figure 1.

Figure 1: Proposed Architecture of RAD-AA framework

We have also analyzed various threat vectors that can manifest in standard
authentication and authorization protocol flows. We have then brought out the
features in the proposed framework that will mitigate the effect of these
threat vectors by anticipating, adapting and withstanding the cyber threats
effectuating in robust and resilient framework.

Roles. The proposed framework defines following roles:

  * •

Resource Owner. It is an entity which is capable of granting access to a
protected resource.

  * •

Resource Server (RS). This server hosts the protected resources and is capable
of accepting and responding to protected resource requests based on the access
tokens and scopes.

  * •

Client. This is an application which makes request for accessing protected
resource requests on behalf of the resource owner after due authorization by
the resource owner.

  * •

Authorization Server (AS). This server issues access tokens to the client
after successfully authenticating the resource owner and obtaining
authorization.

  * •

Adaptive Engine. This engine analyses various transactions in the protocol
flow. It then assigns the risk score which is used by various entities like
authorization server, resource server to modify their behaviour by making the
security requirements more stringent or to limit or deny access to the
protected resources.

###  V-B Protocol Flow and Threat Vector vs RAD-AA Resilience Matrix

The summary of the cyber resilience features of RAD-AA vs the common threat
vectors is given at Table II.

TABLE II: Summary: Common Threat Vectors vs RAD-AA Resilience Matrix

Threat Vectors |  RAD-AA Cyber Resilience Features
---|---
Client Impersonation |  Mutual authentication using mTLS [15] or DPoP [17].
Cross-Site Request Forgery (CSRF) |  AS supports Proof Key for Code Exchange (PKCE) [18].
Authorization Server (AS) Mix-Up attack |  Validation of the issuer of the authorization response.
Cross-Origin Resource Sharing (CORS) |  • Establish trust relationships through mutual authentication. • Calculate risk score before allowing transactions. • Information in HTTP request is assumed fake.
Cross Site Scripting (XSS) |  • CSP headers. • Input validation.
DDoS on AS |  • Check HTTP request parameters are not pointing to unexpected locations, RFC 9101 [19]. • Adaptive engine to thwart malicious requests based on the risk score and the trust relations between the client applications and the authorization server.
Access Token Injection |  Audience restricted token binding.
Access Token Replay |  Sender-constrained and audience-restricted access tokens.

####  V-B1 Risk Score Based Adaptive Engine

The adaptive engine will determine the risk score of each transaction in the
protocol flow based on AI/ML models. It will provide its inputs to all the
entities in the ecosystem such as authorization server and the protected
resource server. The engine will take into consideration various parameters
such as the level of trust relation between the sender and the receiver, Geo-
location, impossible travel, IP reputation, and device information and then
classify the transaction into LOW, MEDIUM and HIGH risks.

The authorization server and the protected resource server based on the
classification of the transaction can do either of the following:

  * •

Raise the security requirements. The security requirements of the transaction
can be made more stringent by demanding the sender to provide additional
verification details.

  * •

Accept or limit/Reject the Request. The AS/RS based on the risk score of the
transaction can either accept the transaction or lower the authorization of
the scopes or completely reject the transaction as a high risk transaction.

The authorization and access to the protected resources will still be governed
by the requirements specified in the protocol. The engine will only classify
the transaction cost as an additional security layer. The engine
classification at no time will bypass the requirements of other validation
requirements as given in the specifications. The common risks associated with
the adaptive engine which are ordinarily associated with AI/ML engines must be
taken into consideration[20].

####  V-B2 Establishment of Mutual Trust

The client applications like native desktop or mobile app, JavaScript based
Single Page App or the web server based web apps need to establish a level of
trust while authenticating their identities with the AS/RS. Each such client
authentication will be assigned a trust assurance level which will regulate
the ability of the client application to acquire elevated authorization rights
or scopes for an extended duration.

  * •

Trust Assurance Level 0. This is the minimum trust assurance level. The
application does not have means of mutual identification and authentication.
The delegated authorization rights would be restricted to a minimum level of
permissions (scopes). The lifespan of the delegated authorization rights (in
terms of access and refresh tokens) will be minimal or for one time use only.

  * •

Trust Assurance Level 1. client application has the means of establishing
mutual identification and authentication by using mTLS[15] or DPop[17]. The
delegated authorization rights/scopes will be more permissive in nature with
an extended lifetime validity.

Threat Vector. Client Impersonation.

Threat Description and Artifacts. The identity of the client application can
be spoofed and a malicious client can impersonate as a genuine client.

Mitigating Features. In the proposed framework the client and authorization
server needs to establish a trust relation by mutually identifying and
authenticating each other by using mTLS [15] or DPoP [17] or similar such
standards.

####  V-B3 Authorization Request

The client application will initiate the request to the authorization server
for grant of access rights to acquire the protected resources owned by the
resource owner. The resource owner will authorize the scopes that the
authorization server should grant to the requesting client. The access rights
of the client will be constrained and restricted to the scopes authorized by
the resource owner. The authorization server will first verify the identity of
the resource owner by passing the request to the federated identity management
system [21].

The Pushed Authorization Requests (PAR) as defined in RFC 9126 [13] will be
used to initiate the authorization request by the client.

Threat Vector. Cross-Site Request Forgery (CSRF).

Threat Description and Artifacts. Clients Redirect / Request URIs are
susceptible to CSRF.

Mitigating Features. The framework prevents CSRF attacks against client’s
redirect / request URIs by ensuring that the authorization server supports
Proof Key for Code Exchange (PKCE)[18]. The CSRF protection can also be
achieved by using "nonce" parameter, or "state" parameter to carry one-time-
use CSRF tokens.

Threat Vector. Authorization Server (AS) Mix-Up attack.

Threat Description and Artifacts. The AS attack can manifest when multiple AS
are used in which one or more is a malicious AS operated by the attacker.

Mitigating Features. The framework prevents mix-up attacks by validating the
issuer of the authorization response. This can be achieved by having the
identity of the issuer embedded in the response claim itself, like using the
"iss" response parameter.

Threat Vector. Cross-Origin Resource Sharing (CORS) attacks.

Threat Description and Artifacts. CORS allows web applications to expose its
resources to all or restricted domains. The risk arises if the authorization
server allows for additional endpoints to be accessed by web clients such as
metadata URLs, introspection, revocation, discovery or user info endpoints.
These endpoints can then be accessed by web clients.

Mitigating Features. In the proposed framework we establish trust and
calculate risk score before allowing any transactions. It is accepted that
access to any of the resources as all the information contained in the HTTP
request can be faked.

Threat Vector. Cross Site Scripting (XSS) attacks.

Threat Description and Artifacts. Cross-Site Scripting (XSS) attack risk
arises when the attacker is able to inject malicious scripts into otherwise
benign and trusted websites.

Mitigating Features. Best practices like injecting the Content-Security-Policy
(CSP) headers from the server are recommended, which is capable of protecting
the user from dynamic calls that will load content into the page being
currently visited. Other measures such as input validation are also
recommended.

Threat Vector. DDoS Attack on the Authorization Server.

Threat Description and Artifacts. A large number of malicious clients can
simultaneously launch a DoS attack on the authorization server by pointing to
the "request_uri" as defined in PAR RFC 9126 [13].

Mitigating Features. To mitigate the occurrence of such an attack, the server
is required to check that the value of the "request_uri" parameter is not
pointing to an unexpected location as recommended in the RFC 9101 [19].
Additionally, the framework employs an adaptive engine to thwart such requests
based on the risk score and the trust relations between the client
applications and the authorization server.

####  V-B4 Delegation of Access Rights

Once the resource owner has authorized the request, authorization grant has
been received by the resource owner and the request received from the client
application is valid, the authorization server issues access tokens and
optional refresh tokens as defined in RFC 6749 [3].

Threat Vector. Access Token Injection.

Threat Description and Artifacts. In this attack, the attacker attempts to
utilize a leaked access token to impersonate a user by injecting this leaked
access token into a legitimate client as defined in draft OAuth 2.0 Security
Best Current Practice, 2022 [14].

Mitigating Features. In the proposed framework, the token is issued after
binding to the client application.

####  V-B5 Accessing Protected Resources

The client application can access protected resources by presenting the access
token to the resource server as defined in OAuth 2.0 RFC 6749 [3]. The
resource server will then check the validity of the access token. It will also
ensure that the token has not expired and that the requested resource is
conformance with the scopes authorized in the token.

Threat Vector. Access Token Replay Attack.

Threat Description and Artifacts. An attacker can attempt to replay a valid
request to obtain or modify/destroy the protected resources as defined in
OAuth 2.0 threat model RFC 6819 [4].

Mitigating Features.The proposed framework mandates sender-constrained and
audience-restricted access tokens as defined in draft OAuth 2.0 Security Best
Current Practice, 2022 [14]. In addition, the resource server may reduce the
scope or completely deny the resource based on the risk score of the client
application from where the request has materialized.

###  V-C ML based Classification approach for Adaptive Engine

The adaptive engine can employ various ML algorithms or models to classify the
transaction data into HIGH, MEDIUM or LOW risk on a real-time basis. Though
there is a high chance that data received by the adaptive engine can be noisy,
the K-Nearest Neighbour (KNN) [22] or Random Forest (RF) [23] can be adopted
based on their capability to work with multidimensional feature sets. RF
requires a large training dataset that can be gradually built into the cloud
based system and later used. Adoption of Incremental Machine Learning (IML)
[24] approaches over the adaptive engine can provide more accurate
classification as it continuously trains the model and over a period of time.

The output of the adaptive engine is taken into consideration by various
systems to grant or deny permissions or accept/reject or terminate the
transaction, and restart the process. Some important features that can provide
a high degree of correlation to classify the transaction data are tabulated in
Table III.

TABLE III: Classification Features Features |  Descriptions
---|---
IP reputation |  The IP reputation will let the system know if the request is coming from an IP with a bad reputation.
Geo Location |  This will identify the geo location of the transaction.
Impossible Travel |  This feature will indicate if the same user has connected from two different countries or geographical locations and the time between these locations can’t be covered through conventional travel means.
Device Info |  Device information will provide the necessary data about the device being used by the client application.
NIDS output |  It will take Netflow data as input stream and classify data as malicious or benign.
Trust Assurance Level |  Trust Assurance Level will determine the degree of trust that server can have on the client application based on the verifiable client identity.
Figure 2: Use of ML Based Classification in Adaptive Engine

The Network Intrusion Detection System (NIDS) will take Netflow data as an
input stream. The output of NIDS will become one of the input features for the
adaptive engine. Trust Assurance Level is an important feature based on the
client applications’ verifiable identity and authentication. A client
application that can authenticate itself by using various
technologies/protocols like mutual-TLS will have a higher trust assurance
level than client applications that cannot authenticate themselves. The model
or the algorithm can be fine-tuned by adding other features, hyper-parameters
or removal/addition of necessary weights or biases for some features over
others.

##  VI Conclusion and Future work

This paper presents the design considerations and architecture for a Resilient
Risk-based Adaptive Authentication and Authorization (RAD-AA) Framework. The
proposed framework achieves higher level of resilience than the existing
frameworks such as OAuth 2.0, OpenID Connect and SAML 2.0 with the help of
adaptive engine based on risk score and trust relationship. In future, we aim
to continue developing this framework and consider further aspects related to
its deployment on different platforms using ML.

## References

  * [1] I. Security, “Cost of a data breach report,” Tech. Rep., July 2022. [Online]. Available: https://www.ibm.com/security/data-breach
  * [2] Y. Su, B. Ahn, S. R. Alvee, T. Kim, J. Choi, and S. C. Smith, “Ransomware security threat modeling for photovoltaic systems,” in _2021 6th IEEE Workshop on the Electronic Grid (eGRID)_. IEEE, 2021, pp. 01–05.
  * [3] D. Hardt, “The OAuth 2.0 Authorization Framework,” RFC 6749, Oct. 2012. [Online]. Available: https://www.rfc-editor.org/info/rfc6749
  * [4] T. Lodderstedt, M. McGloin, and P. Hunt, “OAuth 2.0 Threat Model and Security Considerations,” RFC 6819, Jan. 2013. [Online]. Available: https://www.rfc-editor.org/info/rfc6819
  * [5] N. Sakimura, J. Bradley, M. Jones, B. De Medeiros, and C. Mortimore, “Openid connect core 1.0,” _The OpenID Foundation_ , p. S3, 2014. [Online]. Available: https://openid.net/specs/openid-connect-core-1_0.html
  * [6] T. Groß, “Security analysis of the saml single sign-on browser/artifact profile,” in _19th Annual Computer Security Applications Conference, 2003\. Proceedings._ IEEE, 2003, pp. 298–307.
  * [7] S. Cantor, J. Moreh, R. Philpott, and E. Maler, “Metadata for the oasis security assertion markup language (saml) v2. 0,” 2005.
  * [8] A. Shostack, “Experiences threat modeling at microsoft.” _MODSEC@ MoDELS_ , vol. 2008, p. 35, 2008.
  * [9] T. UcedaVelez and M. M. Morana, _Risk Centric Threat Modeling: process for attack simulation and threat analysis_. John Wiley & Sons, 2015.
  * [10] R. T. Fielding, _Architectural styles and the design of network-based software architectures_. University of California, Irvine, 2000.
  * [11] M. Masse, _REST API design rulebook: designing consistent RESTful web service interfaces_. ” O’Reilly Media, Inc.”, 2011.
  * [12] T. Bray, “The JavaScript Object Notation (JSON) Data Interchange Format,” RFC 8259, Dec. 2017. [Online]. Available: https://www.rfc-editor.org/info/rfc8259
  * [13] T. Lodderstedt, B. Campbell, N. Sakimura, D. Tonge, and F. Skokan, “OAuth 2.0 Pushed Authorization Requests,” RFC 9126, Sep. 2021. [Online]. Available: https://www.rfc-editor.org/info/rfc9126
  * [14] T. Lodderstedt, J. Bradley, A. Labunets, and D. Fett, “OAuth 2.0 Security Best Current Practice,” Internet Engineering Task Force, Internet-Draft draft-ietf-oauth-security-topics-20, Jul. 2022, work in Progress. [Online]. Available: https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/20/
  * [15] B. Campbell, J. Bradley, N. Sakimura, and T. Lodderstedt, “OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens,” RFC 8705, Feb. 2020. [Online]. Available: https://www.rfc-editor.org/info/rfc8705
  * [16] J. Singh and N. K. Chaudhary, “Oauth 2.0: Architectural design augmentation for mitigation of common security vulnerabilities,” _Journal of Information Security and Applications_ , vol. 65, p. 103091, 2022.
  * [17] D. Fett, B. Campbell, J. Bradley, T. Lodderstedt, M. Jones, and D. Waite, “OAuth 2.0 Demonstrating Proof-of-Possession at the Application Layer (DPoP),” Internet Engineering Task Force, Internet-Draft draft-ietf-oauth-dpop-10, Jul. 2022, work in Progress. [Online]. Available: https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/10/
  * [18] N. Sakimura, J. Bradley, and N. Agarwal, “Proof Key for Code Exchange by OAuth Public Clients,” RFC 7636, Sep. 2015. [Online]. Available: https://www.rfc-editor.org/info/rfc7636
  * [19] N. Sakimura, J. Bradley, and M. Jones, “The OAuth 2.0 Authorization Framework: JWT-Secured Authorization Request (JAR),” RFC 9101, Aug. 2021. [Online]. Available: https://www.rfc-editor.org/info/rfc9101
  * [20] S. McLean, G. J. Read, J. Thompson, C. Baber, N. A. Stanton, and P. M. Salmon, “The risks associated with artificial general intelligence: A systematic review,” _Journal of Experimental & Theoretical Artificial Intelligence_, pp. 1–15, 2021.
  * [21] E. R. Hedberg, M. Jones, A. Solberg, J. Bradley, and G. D. Marco, “Openid connect federation 1.0 - draft 20,” _The OpenID Foundation_ , June 2022. [Online]. Available: https://openid.net/specs/openid-connect-federation-1_0.html
  * [22] L. E. Peterson, “K-nearest neighbor,” _Scholarpedia_ , vol. 4, no. 2, p. 1883, 2009.
  * [23] G. Biau and E. Scornet, “A random forest guided tour,” _Test_ , vol. 25, no. 2, pp. 197–227, 2016.
  * [24] R. J. Solomonoff, “Progress in incremental machine learning,” in _NIPS Workshop on Universal Learning Algorithms and Optimal Search, Whistler, BC_. Citeseer, 2002.