API Gateway & OAuth & API key

References

• RFC 6749 - The OAuth 2.0 Authorization Framework

• RFC 7636: Proof Key for Code Exchange

• RFC 8628 OAuth 2.0 Device Authorization Grant

• RFC 7523 - JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants

image link

OAuth goal wasn't for single-sign-on

OAuth was created as a delegated authorization protocol. It has been extended to be used as a single-sign-on protocol through things like OpenID Connect, but that was not its original goal.

API gateway & API key

client_id
client_secret
domain

API Key Security

• https://developers.google.com/maps/api-security-best-practices

  the mobile client shouldn't save secret key but use

  Restriction type	Description
  HTTP referrers	Specify one or more referrer web sites. Wildcard characters are acceptable for authorizing all subdomains (for example, *.google.com accepts all sites ending in .google.com).
  IP addresses	Specify one IPv4 or IPv6 address or a subnet using CIDR notation. Since a web service web service request checks and compares the external IP address against the API key restriction, use the server's public IP address.
  Android apps	Add your SHA-1 signing-certificate fingerprint and your Android package name from your AndroidManifest.xml file.
  iOS apps	Below the types, select the appropriate iOS bundle identifier from the list.

Overview of API access  |  Cloud Endpoints with OpenAPI  |  Google CloudGoogle Cloud

Authentication between services  |  Cloud Endpoints with OpenAPI  |  Google CloudGoogle Cloud

Why and when to use API keys  |  Cloud Endpoints with OpenAPI  |  Google CloudGoogle Cloud

securityDefinitions:
  service-1:
    authorizationUrl: ""
    flow: "implicit"
    type: "oauth2"
    x-google-issuer: "[e-mail]"
    x-google-jwks_uri: "https://www.googleapis.com/robot/v1/metadata/x509/[e-mail]"

API Key & Secret key Design

API Key

• client_id

• domain

Token types

Reference Tokens

Pros

• very simple it's basically hash table which means we can use a database

• easy to revoke

• token data is not visible

Cons

• must be stored

• requires a network to validate

Self-Encoded Tokens

JWT is one of the famous Self-Encoded Tokens.

RFC 7523 - JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants

is the standard for JWT based Self-Encoded Tokens

Pros

• don't need to shared storage

• can be validated without network

Cons

• JWT contents are visible

• No way to revoke

token manage strategy instead of revoke

when publish token describes

field		values	purporse
x_client_id
x_client_type		string [internal, 3rd-party, etc...]	dispatch logic
x_token_type
x_token_version		string [v0.1, v1.0, v2.1, etc...]	for manage token migration
x_domain
iss (standard)	issuer	UUID	logging (do not recommend control API through this.)
jti (standard)	JWT ID	UUID	same client can issues multiple token. so token_id is not an option for logging
iat (standard)	Issued At Time Clame	number	it's standard field for 'Issued At Time claim'
expires_in (standard)		number

Secret key strategy with JWT

here is JWT structure

JWT = HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  '{OUR_JWT_SEED}'
) secret base64 encoded

SECRET_KEY = HMACSHA256(
  base64UrlEncode(${PREFIX}) + "." +
  base64UrlEncode(${JWT}),
  '{OUR_SECRET_KEY_SEED}'
) secret base64 encoded

which means we don't need to save SECRET_KEY

because we can generate on server in real time.