Authentication

You can set up an AuthConfig to enforce authentication for Portal APIs. The following authentication methods are supported:

API keys

API keys are a simple way to protect access to your API products. Only requests that present a valid API key are authenticated. Requests without a valid API key are denied. Keep in mind that API keys make no guarantees about the user’s identity, do not support a single sign-on (SSO) authentication strategy, and can more easily be shared and leaked.

Portal admins have the option to create an AuthConfig that can validate API keys or enable self-service of API key credentials via the Portal frontend app. This way, Portal users can create their own API keys that are automatically stored in the Portal database and scoped to a team, app, and API subscription that the user is part of.

To learn more about this setup, see API keys.

OAuth clients

To allow the Portal server to manage clients in your OIDC provider, you can deploy Gloo Portal IdP Connect. IdP Connect allows your users to use the portal server frontend, instead of navigating to the OIDC provider, to create OAuth credentials.

The OAuth credentials grant access to the ApiProducts that the approved Apps that are subscribed to. Your users get access to the Apps through the Teams that they are a part of through the portal frontend. When you apply an OAuth policy to require credentials from the IdP to access your ApiProducts, your users can then use the OAuth credentials that they self-serviced to access the underlying APIs.

To learn more about this setup, see OAuth.

Authorization

You can control visibility of private APIs in the frontend portal by using PortalGroups. Only users with an ID token that includes the correct claims are authorized to view private APIs in the API catalog.

For more information, see Set up AuthZ with PortalGroups.

Rate limiting

You can limit the number of requests that you want to allow for a partifular API product by using a RateLimitConfig. Rate limiting can be applied on several layers, such as an entire API, an app, or an API subscription. Rate limits on an API subscription overwrite limits on an app, which overwrite the rate limits for an entire API. That way, you have fine grained control over where you want to apply a particular rate limit.

Default rate limit for an entire API

You can apply a RateLimitConfig to limit requests to an API. The rate limit is applied to the API route and therefore shared by all teams and apps that are subscribed to that API.

For more information, see Set up rate limits for APIs.

Rate limiting with dynamic metadata

You might want to customize the rate limiting settings for a particular team or app and not use the default rate limiting settings. With Gloo Portal, you can use the dynamicMetadata feature in a RateLimitConfig to overwrite any default rate limits with the limits that were configured via the Portal frontend app for a particular app or API subscription. If no custom rate limit exists for an app or API subscription, the default rate limits are still enforced.

To learn more about this feature, see Set up rate limits for APIs.