AWS AppSync and the API Key
The strange relationship between API Keys and AppSync
Since working with AWS AppSync I’m puzzled by the statements like this:
API Keys are recommended for development purposes or use cases where it is safe to provide public access to an API without specific authentication requirements (i.e. guest users).
API Keys are very common for public access APIs, for example the Twitter API, instead of a user, you are using an API Key to get access to resources.
- Simplified Access
- Easily to integrate in applications
- Established protocol
- An API Key could be stolen and used against its user
So API Keys aren’t flawless (like most things), but very useful in backend applications.
It is recommended to use API keys when you are getting started with the API development, want to iterate quickly, and don’t want to worry about more complicated authorization methods.
That is very puzzling, does that mean that all existing API Keys out there only exists because the other services did fail to do it better, and that with AppSync and Cognito there is finally the one and only solution?
AppSync Methods of Authorisation
- API Keys
- IAM (AWS internal authorization, identity access management)
- OIDC (OpenID Connect, plug in external authorization systems)
- Cognito (AWS authorisation system)
Frontend facing GraphQL API which is accessing backend APIs from micro services.
I need to access the GraphQL API to be accessed by a Web client and also an SDK/backend tools (currently inPython).
The web client is accessing the shop API using Cognito users. The backend tools should access the Shop API.
In that scenario, the shop is an identity, in that case the shop is a legal person not a natural person. Cognito and also OIDC are build primarily for users which are natural persons not legal persons.
OIDC and Cognito also don’t offering dedicated service accounts for legal persons. A legal person usually is not interacting with a web service using a web client, instead they use service accounts.
There are practical and legal reasons for that. An user working for a company (legal entity) is working on behalf of that legal entity, and the actions of this user needs to be logged for example for compliance.
A legal entity interacting directly with a web service is in that sense acting on its own. The user management of Cognito and OpenID auth providers is mainly build for human users. So they do not support legal persons out of the box.
API Keys and IAM roles/users on the other hand can be regarded as mechanism to manage the identities of legal persons. An API Key works as such, there is no eMail or Password, it is possible to link an API Key with exactly one legal entity (shop) and only one legal entity.
The same is possible with IAM roles&users, the difference is here, that an IAM role or user is managing the access to system resources in AWS, an API Key is foremost a mechanism to manage application access.
Which means an API Key is easier to manage security wise, using an IAM role&user needs more considerations (read time&effort).
Currently I’m trying to solve that problem as elegant as possible (a heavy handed approach using Lambdas, or duplicating data is always possible, but no elegant or efficient).
I will try to use an API Key (managed by my application) to give access to the frontend facing Shop API, and either use a secondary API Key for backend service access (clumsy) or use IAM roles.
- IAM/Open ID are good for natural persons
- API Keys/IAM are good for legal persons
Problem is, that AWS AppSync is not supporting security management out of the box, if you are trying to integrate more than one API.
It all works flawlessly and easily if you are using Amplify with only a single GraphQL API. In the moment you are trying to integrate backend services (micro or macro does not matter), the effort to implement and design access and security is increasing dramatically.
Which means migrating towards AppSync from an existing solution needs some carefully planning regarding service integration and security design.