Direkt zum Hauptbereich

Attacking OpenID Connect 1.0 - Malicious Endpoints Attack

In this post we show a novel attack on OpenID Connect 1.0, which compromises the security of the entire protocol - the Malicious Endpoints attack. The idea behind the attack is to influence the information flow in the Discovery and Dynamic Registration Phase in such a way that the attacker gains access to sensitive information.

OpenID Connect authentication flow with Discovery and Dynamic Registration

OpenID Connect 1.0 protocol flow with Discovery and Dynamic Registration

  1. Initiate Single Sign-On:
    An End-User visits the client (https://honestClient.com) and starts the Single Sign-On authentication in order to authenticate on the Client and get access to his resources. For this purpose, the End-User enters his identity on the Honest OP (e.g. alice@honestop.com).
  2. Discovery Endpoint (Discovery):
    The Client normalizes the entered identity in order to estimate the correspondig OP. Afterwards the Client sends an HTTP request to this Discovery endpoint and subsequently retrieves the OP's confguration information including its endpoint locations: 
    1. The (Dynamic) Registration Endpoint (regEndp).
    2. The Authentication Endpoint (authEndp.
    3. The Token Endpoint (tokenEndp).
  3. Using the Registration Endpoint (regEndp):
    In order to use OpenID Connect services for authentication, a Client has to register on the OP. For this registration, the Client accesses this URL regEndp, for example, https://google.com/register.
  4. Using the Authorization Endpoint (authEndp):
    In order to execute the Client's Authentication Request, the End-User has to be redirected to the authEndp of the OP, for example to https://login.google.com/. Here, the End-User has to authenticate to the OP via a corresponding authentication process and authorize the Client to access the requested resources.
  5. Using the Token Endpoint (tokenEndp):
    The Client communicates with the tokenEndp, for example, https://google.com/consume-token, in order to obtain the id_token described in Section 2.5 and authenticate the End-User. In addition, an access_token can be sent to the Client in order to authorize the access to restricted resources. This communication is done directly between Client and OP (without involving the End-User).

Malicious Endpoint Attack

A view of the Malicious Endpoint attack and the protocol flow.

    Phase 1.1 - Injecting malicious endpoints: The attacker's intention in the first phase is to force a valid Client to use the attacker's malicious Discovery service. For this purpose, he constructs a malicious link and sends it to the End-User. For example, this can be a link to the valid Client containing an identity alice@malicious.com.
    If the victim clicks on the constructed link and thus visits the Client, the Client starts a discovery phase with the malicious Discovery service http://malicious.com. The Client sends a request to determine the corresponding endpoints. The attacker's Discovery service responds with the following values, initiating the actual attack:
    Malicious Endpoints
    issuer http://malicious.com
    regEndp https://honestOP.com/register
    authEndp https://login.honestOP.com/
    tokenEndp http://malicious.com
    userInfoEndp http://malicious.com

    Phase 1.2 - Dynamic Registration In the next step, the Client accesses regEndp for the Dynamic Registration. It sends a registration request to https://honestOP.com/register and receives a client_id and client_secret in the response.
    The Client automatically starts the Dynamic Registration, even if it is already registered on the honest OpenID Provider. The reason for this behavior is that the Client believes that http://malicious.com is the responsible op, since it is not known from previous authentication procedures. Thus, http://malicious.com is a new OpenID Provider for the Client and it starts the registration procedure.

    Phase 2 - End-User Authentication and Authorization In the next phase, the Client redirects the End-User to authEndp, https://login.honestOP.com/, where the End-User has to authenticate himself and authorize the Client. The End-User is not able to detect any abnormalities in the protocol flow: Phase 1.1 and Phase 1.2 cannot be observed by the End-User, and in Phase 2 the End-User will be prompted to authenticate to the honest OpenID Provider and authorize the honest Client, both of which he knows and trusts. Thus, the End-User authorizes the Client and the OpenID Provider generates the code, which is sent to the Client.
    Note: Phase 2 exactly follows the original OpenID Connect protocol flow -- there is no parameter manipulation, no redirects to malicious websites and no observation of the network traffic between the End-User, the honest OpenID Provider and the Client. This means that the attack cannot be detected by the Client, the OpenID Provider and the End-User.

    Phase 3 - The Theft In dependence of the protocol flow (Code or Implicit) the messages sent to the attacker differ.
    Code Flow: Within the Code flow the Client redeems the received code from the previous phase: It sends the code together with the corresponding Client's credentials received during the Dynamic Registration (client_id/client_secret) to the tokenEndp originally specified by the malicious Discovery service - in this example http://malicious.com.
    Implicit Flow: Since the Implicit flow does not use the tokenEndp, the attacker is not able to receive the information send in phase 2. But during the Discovery Phase an other malicious endpoint can be used - userinfo_endpoint. This endpoint is an OAuth 2.0 Protected Resource that returns Claims about the authenticated user. According to the specification, the obtained access token is sent as a Bearer token by the Client. Thus, the attacker can get access to a valid access token.


      You can run our demo on:

      Authors of this Post

      Vladislav Mladenov
      Christian Mainka (

      Beliebte Posts aus diesem Blog

      How To Spoof PDF Signatures

      One year ago, we received a contract as a PDF file. It was digitally signed. We looked at the document - ignoring the "certificate is not trusted" warning shown by the viewer - and asked ourselfs:

      "How do PDF signatures exactly work?"

      We are quite familiar with the security of message formats like XML and JSON. But nobody had an idea, how PDFs really work. So we started our research journey.

      Today, we are happy to announce our results. In this blog post, we give an overview how PDF signatures work and on top, we reveal three novel attack classes for spoofing a digitally signed PDF document. We present our evaluation of 22 different PDF viewers and show 21 of them to be vulnerable. We additionally evaluated 8 online validation services and found 6 to be vulnerable.

      In cooperation with the BSI-CERT, we contacted all vendors, provided proof-of-concept exploits, and helped them to fix the issues and three generic CVEs for each attack class were issued: CVE-2018-16042

      DTD Cheat Sheet

      When evaluating the security of XML based services, one should always consider DTD based attack vectors, such as XML External Entities (XXE) as,for example, our previous post XXE in SAML Interfaces demonstrates.

      In this post we provide a comprehensive list of different DTD attacks.

      The attacks are categorized as follows:
      Denial-of-Service AttacksClassic XXEAdvanced XXEServer-Side Requst Forgery (SSRF)XIncludeXSLT

      Practical Dictionary Attack on IPsec IKE

      We found out that in contrast to public knowledge, the Pre-Shared Key (PSK) authentication method in main mode of IKEv1 is susceptible to offline dictionary attacks. This requires only a single active Man-in-the-Middle attack. Thus, if low entropy passwords are used as PSKs, this can easily be broken.