Platform security – this is how content can be protected and securely exchanged

Note: We have used commission links in this article and marked them with “*”. If an order is placed via these links, t3n.de receives a commission.

When setting up digital platforms, it must be ensured, among other things, that user information can be exchanged securely and easily. This is how it works.

Commercial platforms enable various actors to close deals, initiate operational processes and mediate business services between participants. But caution is advised when setting up such platforms: Not only against the background of the GDPR, security and data economy must be taken into account as central aspects in the platform architecture. Which technologies are suitable for federalizing login data and profile information without collecting security-critical user profiles?

Let’s take a look at OAuth first. In the modern world of social media, each of us uses dozens of applications and websites every day. In order not to have to constantly create a new profile for each individual provider, the OAuth authorization protocol has been developed on the initiative of Facebook and Twitter since 2012. It describes how previously mutually known services can securely access their resources on behalf of their users without sharing the specific login information. In this way, an account that has already been created (for example on Facebook or Google) can be used to log in to other services without revealing your password or email address. In broad terms, OAuth works as follows.

Let’s assume Melanie wants to register with Aliexpress and selects “Sign up with Google” as one of the options offered:

1. Aliexpress creates a URL to Google’s registration service, which contains the desired profile areas (scopes) required by Melanie’s profile, and redirects Melanie’s browser to this URL.
2. Google recognizes that the request comes from Aliexpress and points out to Melanie what information and Google services Aliexpress will be able to use if she agrees.
3. Melanie gives Google permission to release the data from the desired scopes to Aliexpress.
4. The Google API sends a one-time grant token to Aliexpress, which the service replies with a secret negotiated between it and Google in order to be able to uniquely identify Aliexpress.
5. Google responds with an access token that represents Melanie’s authentication and approvals.
6. Aliexpress transmits Melanie’s access tokens to one of the authorized Google APIs for each request.
7. The Google API check the validity of the token and deliver the requested data to Aliexpress.

The OAuth protocol paved the way for federalized login and authorization protocols. However, it suffers from the strong correlability of metadata: Google learns a lot about the information relationship between Aliexpress and Melanie. Furthermore, the method is heavily dependent on the availability and goodwill on the part of Google and requires that clients can keep tokens and service-specific secrets for themselves and actively acquaint themselves with each other before using the method.

JSON Web Token (JWT) has been a JSON-based specification for security tokens for several years, the integrity of which is ensured using cryptographic signatures. JWT contain all authentication and authorization information of an entity that is relevant for a use case. This eliminates the need to query databases to determine authorizations or to save session data on the server (“stateless session”).

As a result, JSON web tokens have become particularly popular for authentication in distributed system landscapes. After successful identification, an authentication server issues the user with a JWT with authorization information and, if necessary, personal characteristics and signs him with a key pair, the public key of which he can make known to other application servers. As soon as someone presents them with a JWT as an authentication feature, the application servers can check the signature to ensure that the information from the token actually comes from an authentication server that they trust.

JWT are ideal for user authentication in microservice environments. Unlike monolithic backend architectures, they cannot share a session state. In order to authenticate a request and to be able to prove its authorizations, all they need is knowledge of a publicly accessible certificate against which they can verify the signature of the JWT. Registration services can also use this to provide authorizations for third-party systems.

Since JWT are self-sufficient authentication features, their security primarily depends on their users keeping them secret and not being intercepted in transit. Therefore, they are usually only provided with very short-term expiration dates and must be regularly renewed by their users with the help of refresh tokens that are exclusively used for this application.

Also interesting: Hello Token, bye-bye Password! GitHub is set to become more secure in 2021

While OAuth and JWT represent the current standard for platform security, they still suffer from the fact that they are based on a central authentication process and federalized trust. In the future, they will therefore be replaced by so-called self-sovereign identities (SSI). In general, SSI means that people manage their digital identity completely independently (for example in the form of a wallet on a mobile device) and are no longer dependent on a central identity service provider. Instead of exchanging e-mail / password combinations, authentication takes place through proof of control of a so-called decentralized identifier (DID) using digital signatures. Depending on the application, a user can use several DIDs for different aspects of his digital identity. DID essentially represent a collection of keys that can be resolved on publicly accessible systems. Typically, they are not held in an information silo such as a federated Google authentication service, but are resolved to the currently valid version with the help of decentralized, trustless systems such as blockchains. Authorizations are issued using so-called Verifiable Credentials via DID. In turn, they can be presented as JWT. Your legitimacy can be verified by a third party system using the public keys stored in a DID document by the issuer and the authentication subject.

The search for ways and technologies to securely and easily exchange user information on platforms is far from over. While current federalized authentication and rights management procedures have problematic consequences for security, correlability and data protection, self-sovereignly controlled identities confront their users with the responsibility of having to keep their secrets themselves. Decentralized trust services from the world of distributed ledger technologies solve the anchoring and securing of public identifiers, but raise new questions about traceability and usability and are difficult to induce to interoperate with one another. The goal of registering on any system with a self-issued and state-certified identity card without publishing the entire registration history is still ahead of us. By then at the latest, however, the unholy profiling and registration servers of federalized data octopuses could be switched off for good.

You might be interested in that too