Can developers login to the developer portal, view APIs and API docs, and view/manage tokens?

[MaxChen1126]

Hi, Folks . I'm New here and would like to inquire about the original design purpose of APIGEE for developers. Can I configure developers, APP, and Portal as client settings? The envisioned scenario involves allowing users (Developers) to log in to the Portal, where they can view the API swagger for multiple products and see their (APP) tokens. They should also have the freedom to revoke tokens. I'm unsure if this is achievable or if there are recommended practices. Additionally, is there a correspondence between developers and Portal users?

Furthermore, we are planning to separate APIGEE into staging and production environments, both utilizing the Extensible Policies feature. Should we create an additional Intermediate environment (env)? If so, is there a billing option for low usage, or is there a better approach? Thank!

[dchiesa1 · Accepted solution]

Dane wrote

[developers of apps] do not view app tokens..

To add to that ... in Apigee, the developers of apps are the people who login/authenticate to the developer portal to view the API catalog (the Swaggers , as you say). They can manage their own app credentials (client+secret). The apps they build, when they run, will request and receive OAuth tokens. If using 2-legged OAuth, then the token represents the authenticted app. If using 3-legged OAuth, then the token represents an authentiated app and an authenticated user.

In general, it is not a normal "user journey" for a developer of an app to have the ability to revoke tokens that are in use by users of the apps they have built. It is possible for you to build and expose a token revocation endpoint, which would allow the user of the app to revoke the token they currently have. Each user would be able to revoke his own token, if he wished. But this wouldn't allow the developer of the app to revoke tokens. 

Normally, it is a system or program administrator that would revoke a large set of tokens. This would be an extra-ordinary case, often in response to credential leakage. Eg, we know that the credentials for App A have been leaked, so let us revoke all tokens for that App. another scenario is observance of widespread malicious behavior - we see the App A is doing something that is not acceptable (maybe an inadvertent denial of service due to a client-side bug), and so a program administrator can revoke tokens and disable the App credentials to temporarily mitigate that behavior.

The developer of an app could revoke credentials via the developer portal.  That is not the same as revoking tokens.  Credentials are the client+secret (or alternatively, a public key corresponding to a private key).  The developer has control over those. But not the short-lived tokens that get generated from those credentials.

[dknezic]

Yes, your api users/clients can log into the portal.. they can view API documentation/swagger for API products..

However, they do not view app tokens.. they create an app and can view the api key or client key /secret. The client key and secret can then be exchanged for a token that lives for some duration of time (as configured by you) if you're using oauth for authentication for your APIs. 

Client's also do not revoke these tokens.. 

[dchiesa1 · Accepted solution]

Dane wrote

[developers of apps] do not view app tokens..

To add to that ... in Apigee, the developers of apps are the people who login/authenticate to the developer portal to view the API catalog (the Swaggers , as you say). They can manage their own app credentials (client+secret). The apps they build, when they run, will request and receive OAuth tokens. If using 2-legged OAuth, then the token represents the authenticted app. If using 3-legged OAuth, then the token represents an authentiated app and an authenticated user.

In general, it is not a normal "user journey" for a developer of an app to have the ability to revoke tokens that are in use by users of the apps they have built. It is possible for you to build and expose a token revocation endpoint, which would allow the user of the app to revoke the token they currently have. Each user would be able to revoke his own token, if he wished. But this wouldn't allow the developer of the app to revoke tokens. 

Normally, it is a system or program administrator that would revoke a large set of tokens. This would be an extra-ordinary case, often in response to credential leakage. Eg, we know that the credentials for App A have been leaked, so let us revoke all tokens for that App. another scenario is observance of widespread malicious behavior - we see the App A is doing something that is not acceptable (maybe an inadvertent denial of service due to a client-side bug), and so a program administrator can revoke tokens and disable the App credentials to temporarily mitigate that behavior.

The developer of an app could revoke credentials via the developer portal.  That is not the same as revoking tokens.  Credentials are the client+secret (or alternatively, a public key corresponding to a private key).  The developer has control over those. But not the short-lived tokens that get generated from those credentials.

[dchiesa1 · Accepted solution]

we are planning to separate APIGEE into staging and production environments, both utilizing the Extensible Policies feature. Should we create an additional Intermediate environment (env)?

We advise that you build out environments to match your existing SDLC. The use of Apigee should not change that.

If your normal SDLC involves staging and prod, then you should have Apigee staging and prod. Whether those are Apigee ENVIRONMENTS or Apige ORGANIZATIONS is again, dependent upon how you use Google Cloud projects . Keep in mind that you may configure at most ONE Apigee Organization per Google Cloud project. So if you have a Staging project, and a Production Project, in Google Cloud, then you should probably have a staging Organization and a production Organization for Apigee.

If you use an additional environment/project for development, then you should have that for Apigee too.

If so, is there a billing option for low usage, or is there a better approach?

There is a pay-as-you-go option which is pretty low cost. If you are on a subscription, then, it matters less because your overall charge is based on the aggregate of usage across all organizations and environments. In general the cost of Apigee for development environments will not be high. When I see higher costs for Apigee, that is usually driven by large transaction volumes. Like thousands or tens of thousands of requests per second, or more. If you are doing load testing in your dev environment, then those can drive costs, but in my experience, load or soak tests are short-lived and the transaction volume is still much smaller than the production workload. YMMV.