Below we will cover these topics as they apply to API gateways.
Authentication and Authorization
In short, the system uses authentication and authorization processes to answer two questions about a given request:
Who made this request? (authentication);
Is he allowed to do what he is trying to do? (authorization).
This is true whether the request comes from outside or inside the system, such as a request from another service or from an identity and access management (IAM) system. Some tools duplicate both functions. For example, a JSON Web Token (JWT) can be used to identify a user and contain a list of authorized permissions in its payload.
The essence of authentication is to verify the user's bolivia mobile database against a known object and send back credentials that the user must send on subsequent requests, be it a JWT, a session cookie, etc. What you want in an API gateway is built-in compatibility with as many standard authentication methods as possible, and extensibility so that you can use other methods that are not built into the gateway.
Some common authentication methods to look for in an API gateway are:
Basic authentication - also known as "username and password";
OpenID Connect (OIDC) - This tool is used for single sign-on (SSO) by most major providers such as Azure Active Directory, Google, Github, Okta, etc.;
JWT - To get a JWT, the user must authenticate in another way, but the JWT will be sent for future requests as long as the token is valid. Quickly validating a JWT at the entry point is very convenient.
Extensibility
It's common for large business systems to use a non-standard or unusual authentication system for older or very specific services. You may not need to extend your API gateway's authentication system when you first start using it, but it's always nice to know that it's possible. Typically, this takes the form of a feature that lets you configure your API gateway to send a request to an external service you're building and receive an approval or denial response.