Decentralized Identity and API Security
Decentralized identity is something we’ve been talking about a lot at Curity recently. We recognize this technology’s great potential and believe it can be the way to fix the digital identity dilemma. Determining identity is about trust - and the contemporary methods of establishing this trust make the internet identity too tightly coupled. More and more data is being shared to authenticate users and ensure they are who they claim to be.
Here, I will briefly touch upon aspects of decentralized identity that are significant for Curity as our product combines identity and API security. What will be the effect of the decentralized identity paradigm shift on API security? What should companies do to prepare for the shift? And why talk about identity in APIs at all?
Identity and APIs
APIs are everywhere, and they are becoming increasingly business-critical with API security being named a C-level concern by an increasing number of organizations. At the same time, almost every week we get reports about various companies being subject to API attacks and losing multi-million dollars worth of data due to insufficient security measures protecting their systems. It can not be emphasized enough how high the time to protect your APIs is now.
To do this, token-based architecture should be the base of your API security. This first step will allow you to achieve a higher level protection by leveraging claims and incorporating identity into your APIs. You can find many resources on the topic in our resources section and blog, but if I had to choose a couple, then the API Security Maturity Model and API Security Best Practices articles would be a good starting point.
API Security in the Decentralized Identity Paradigm
Say, you moved from API keys, started using access tokens, and established centralized trust with Claims. Would you have to make more changes in the world of decentralized identity? Yes and no.
The shift towards decentralized identities means giving back control over data to the user and it will force us all to rethink our old ways. When using token-based architecture for your API security, it is a good idea to think about these aspects:
No oversharing of information
Tokens should be tailored to keep only relevant data. Therefore, it is of utmost importance to check what information you need to make access decisions. Suppose you want to make an access decision based on country. In that case, you probably don't need the user's postal code, which can reveal more information than needed (City and approximate residence location). Think whether you need to know that a user is a certain age or over a certain age. Or do you need this information at all? With decentralized identities, users will have much greater control over what information they share with your organization, so you should start thinking about how to work with as little user data as possible while retaining the same level of access security.
Identifiers will change
Decentralized identity will bring a new way of onboarding. On one hand, it can facilitate user registration, as users will now present their wallet credentials and your organization will use that data to create an account. No more need for filling in tedious forms. On the other hand, users will be able to authenticate without registering at all — your application will use the user’s digital identity to identify them even though there is no previously registered account. This will change the way you work with user identifiers and you should start preparing for that shift as well, especially if you are using emails as unique identifiers or have a tight coupling between the user’s identifier and the login method used.
Some things stay the same
When building a (decentralized) identity-based API security system, best practices should be implemented. If you must use sensitive data to manage access, it should always be asserted by the OAuth and OpenID Connect server and put into the access token. All the data used for authorization should come from a token, not from context attributes, with a clear distinction between different types of tokens - JWTs can be only used internally, for the public opaque tokens should be used.
Where to start?
To prepare for the decentralized identity paradigm shift, some learning needs to be done. Make sure to check out these resources:
Decentralized Identity and Verifiable Credentials - webinar on demand
Your Wallet, Your Rules - Decentralized Identity and Digital Wallets - webinar on demand
For a more detailed overview of how decentralized identity will change APIs, watch the recording of my Decentralized Identities Change Everything, Even Your APIs talk from Nordic APIs 2023 Platform Summit.
