Token sharing attack

An adversary may request their own credentials from legitimate credential issuers. This requires him to be able to get an authorization code (or pre-authorized code in the respective protocol flow) and obtain an access token. If the adversary is willing to share this data, they can trick victims into starting a flow with a self-hosted, malicious credential issuer. Such situations can occur, for example, in phishing attacks.

The malicious credential issuer modifies its credential endpoint to the credential endpoint of the legitimate credential issuer. In the token endpoint response of the malicious credential issuer, the response includes the adversary's token instead of any token attributed to the end-user. Upon receiving the credential, the unknowing end-user sends a request to the credential endpoint of the legitimate credential issuer with a valid token and receives a credential intended for someone else.

In scenarios, where the user does not verify his received credentials or when the credential content or format do not provide (easily readable) personally identifiable information, this allows an adversary to inject his credentials into a victim's wallet. A real-world example is entry tickets, where tickets often only have limited or no personal data. The new, maliciously loaded tickets could result in worse allocations or even be flagged or invalidated, causing missed events or entries. However, this attack does not make duplicating credentials easily possible, as the pre-authorized code must be short-lived and single-use, according to the specification.

What the specification fails to address properly are limitations on the issuance of these authorization and pre-authorized codes. It could, in theory, issue multiple codes for the same credential, allowing the user to save the credential in various wallets. This again would allow such duplicate credential scenarios. In this scenario, an adversary can use this attack to forward tokens for their credential at will. For the prior example of entrance tickets, if entry control notices a ticket being used twice, a victim can be defined as having entered after the adversary. The threat in this issuance lies in the victim's ignorance that their ticket is a duplicate.

Furthermore, the specification does not address any verification from the end-user or the wallet to be done after the credential was issued. For example, the wallet could try and recognize personally identifiable fields and notify the users, if they find a mismatch. Such situations may be wanted (e.g. a parent saves the credential for their child), but may also be a sign of an attacker having injected a credential instead of one attributed to the end-user. Including a recommended or mandatory presentation for the end-user to check the credential that was just issued improves the end-user experience and increases the security of the credential issuance. This verification step assumes the credential contains either personally identifiable information or information that the end-user can attribute to their personal ticket, such as their selected seats at an event.

No files or tests are named. Start by reviewing the credential issuance specification sections covering authorization and pre-authorized codes, token responses, and post-issuance verification; done means the token-sharing attack and proposed mitigations are resolved in the specification.