An Apigee reference implementation to demonstrate a variety of frequently-used authentication and authorization schemes. Integration tests are included to invoke each endpoint and scheme that is made available by the API Proxy. The list of schemes mentioned and demonstrated here is not a complete or comprehensive list of schemes supported by Apigee.
- API Key Verification (for identification, not authentication)
- Basic Authentication (RFC 7617)
- JWT Verification (RFC 7519)
- OAuth Bearer Token Verification (RFC 6749)
apigee-sackmessernpmand Node.js
To deploy the artifacts, first appropriately set the following environment variables per PIPELINES.md:
export APIGEE_X_ORG=
export APIGEE_X_ENV=
export APIGEE_X_HOSTNAME=
export APIGEE_X_TOKEN=$(gcloud auth print-access-token)Then, execute pipeline.sh:
sh ./pipeline.sh
Note that the pipeline will automatically execute integration tests after a successful deployment. To clean up all artifacts, set the following variable and re-run pipeline.sh:
APIGEE_AUTH_SCHEMES_CLEAN_UP=true; sh pipeline.sh
To run the integration tests, first retrieve Node.js dependencies with:
npm install
and then:
npm run test
For additional examples, including negative test cases, see the auth-schemes.feature file.
Include a valid Client ID in the following request. Instructions for how to find the Client ID (also known as consumer key or API key) can be found here. If the pipeline has been successfully executed, you will see the AuthApp created for testing purposes.
curl -v https://$APIGEE_X_HOSTNAME/auth-schemes/v0/api-key -H "API-Key: $CLIENT_ID"
Note: API key verification should not be considered a strong method of authentication for APIs.
curl -v https://$APIGEE_X_HOSTNAME/auth-schemes/v0/basic-auth -u alex:universe
Note: Under normal circumstances, avoid providing passwords on the command itself using
-u. The credentials used and expected here are for demonstration purposes only.
First obtain a short-lived signed JWT using the helper endpoint:
curl -v -XPOST https://$APIGEE_X_HOSTNAME/auth-schemes/v0/helpers/jwt
Copy the value of the generated-jwt response header from the previous request and include it in the following request:
curl -v https://$APIGEE_X_HOSTNAME/auth-schemes/v0/jwt -H "Authorization: Bearer $JWT"
First obtain a short-lived opaque access token using the helper endpoint. Instructions for how to find application credentials can be found here. If the pipeline has been successfully executed, you will see the AuthApp created for testing purposes.
curl -v -XPOST https://$APIGEE_X_HOSTNAME/auth-schemes/v0/helpers/oauth -u $CLIENT_ID:$CLIENT_SECRET -d "grant_type=client_credentials"
Note: Under normal circumstances, avoid providing secrets on the command itself using
-u
Copy the value of the access_token property from the response body of the previous request and include it in the following request:
curl -v https://$APIGEE_X_HOSTNAME/auth-schemes/v0/oauth-token -H "Authorization: Bearer $TOKEN"
The external-callout-samples repository contains an example implementation for an apigee-ldap-callout which utilises Apigee's ExternalCallout policy. This strategy can be used to verify credentials provided by a client with an LDAP directory service.
Also known as client certificate authentication or mutual authentication, mTLS can be utilised to achieve transport layer authentication of API clients. For implementation details relating to Apigee X, see this two-part community article which comprehensively explains the necessary configuration for enforcing client certificate verification at the API ingress point. For implementation details relating to Apigee hybrid, refer to the official product documentation. In both cases, the API Proxy will have access to the client certificate and a set of certificate attributes available as runtime variables.