...or default to an empty array.

Decide on what type of documentation do we want to use:

• are we fine with the readme and api doc as is?
• do we want to provide additional diagrams/code examples to also explain OAuth 2.0 to a certain degree to really make it easy for the developer to use this lib

Explain how to use the tooling to protect endpoints with oAuth scopes.

For example update node-uuid to uuid to get rid of warning on npm install

The indexer defined on the token type currently lacks type information, as in #81 the return type was explicitly set to any.

In sum, there are two problems present with the current solution:

• The indexer doesn't describe the current shape of the token object
• Types can work as documentation in the case of the indexer
• If the structure changes, it would be also maintainable due to the use of union types.

• Add typings where possible
• Remove Set usage where not needed
• Try to not use any instead of is-a req: express.Request

Currently, there is no way to add query parameters to a server request.
However, there are multiple use-cases:

• add a state parameter to the request (see https://tools.ietf.org/html/rfc6749#section-4.1.1)
• add additional parameters which may be necessary for customised oauth2 implementations (like used inside Zalando with the REALM parameter)

Therefore, the OAuth config object (used in https://github.com/zalando-incubator/lib-oauth-tooling/blob/d222a021d20b2440d3662f0249dd1057fb50c23e/src/oauth-tooling.ts#L155) should be extended by an property queryParameters which accepts a HashMap of key value pairs which will be added to server requests.

Linting is currently not working correctly due to wrong glob expandation.

• Refactor npm scripts
• Code coverage

to show License tab

For example, if authorization header is not set we do not even have to try to call an endpoint, instead fail early (see oauth-tooling.ts).

Furthermore, validation of config in getAccessToken should not just throw but reject the returned promise (see oauth-tooling.ts).

Do some cleanup and increase code coverage

For example the Token type can be improved, instead of:

interface Token {
  access_token: string;
  expires_in: number;
  scope: string;
  token_type: string;
}

we should use something like:

interface Token {
  access_token: string
  expires_in?: number
  scope?: string
  token_type?: string
  [key: string]: {}
}

since we do not know what properties are exactly set on the tokens in different implementations. Furthermore, the Token type should be exported by the library. For the typesToken and Tokeninfo we should check again whether it is necessary to have two types or if one (which is than more generic) is enough.

Currently we depend on [email protected]:graviton/graviton-typings.git, we should change this...

Planned offline meeting about merge topic in CW 26.

See https://tools.ietf.org/html/rfc6749#section-1.5 and https://tools.ietf.org/html/rfc6749#section-6

Example request:

curl -X POST
  -d scope="uid cn"
  -d grant_type=refresh_token 
  -d refresh_token=2165465e-XXXXXX 
  -u 'stups_greendale-auth-demo_2ff5c86e-a8a2-4f54-84a1-077d73dbe1b4'
  https://auth.zalando.com/z/oauth2/access_token?realm=employees

Response:

  {
    "scope":"uid cn",
    "expires_in":3599,
    "token_type":"Bearer",
    "access_token":"cb56610f-XXXXX"
  }

1. For better support of internal open source tooling, we should have a file containing the maintainers. (DONE in #68)
2. CatWatch. Is this also need for incubator projects?
3. More stuff we could takle with this issue?
4. Contributing.md see #20

https://github.com/TypeStrong/typedoc

In the documentation under oauthConfig, the config values should be entered using strings, for example 'PASSWORD_CREDENTIALS_GRANT' for grant type. Expected from the lib are not strings but constants, like PASSWORD_CREDENTIALS_GRANT = 'password'. So in order to enter a working configuration, the constant have to be entered, or a 'password' string. There should be a description on how to import and use the constants.

Requirements to move authmosphere out of the incubator

• #24
• #15
• Remove last Zalando dependencies
• Any other issues required to be resolved?

Add

  "publishConfig": {
    "registry": "https://registry.npmjs.org/"
  },

to package.json to make sure that the public registry is used when publishing the package.

We consume different services and access_tokens via the 'tokenCache' implementation.
Therefore we used this construct in different places and several times:

function getAccessToken() {
  return tokenCache.get("specific_key")
                .then(tokeninfo => tokeninfo.access_token);
}

Our solution is to provide a factory which can be consumed to access a specific key:

function accessTokenFactory(key: string): () => Promise<string> {
   return function () { 
      return tokenCache
               .get(key)
               .then(tokenInfo => tokenInfo.access_token);
  };
}

Maybe this function could be handy in the library as well 😄

Instead add mocha, ts-node, typings and typescript, to the devDependencies.

See https://github.com/zalando-incubator/lib-oauth-tooling/search?utf8=%E2%9C%93&q=cn&type=

In projects having [email protected] and this lib (which uses [email protected]) as dependency a npm bug (npm/npm#10727) causes problems when running npm install twice.

https://github.com/zalando-incubator/lib-oauth-tooling/blob/master/src/express-tooling.ts#L40

precedenceFunction(req, res, next)
.then(result => {
  if (result) {
    next();
  } else {
     validateScopes(req, res, next, scopes);
  }
});

If precendenceFunction throws an error this is not handled well.
There should be an catch clause that executes and error handler that is passed by from the calling function.
This handler would allow the application to answer with an 500 or 403 or whatever is intended.

I suggest to change the API:

interface IPrecedenceFunction {
  (req: any, res: any, next: Function): Promise<boolean>;
}

interface IPrecedenceOptions {
  precedenceFunction: IPrecedenceFunction,
  precedenceErrorHandler: Function
}

function requireScopesMiddleware(scopes: string[],
                                 precedenceOptions?: IPrecedenceOptions) {

Use

interface Token {
  access_token: string;
  expires_in?: number;
  scope?: string[];
  token_type?: string;
  local_expiry?: number;
  [key: string]: any; // <= instead of[key: string]: {};
}

to fix type errors with strict typescript configurations.

In the TokenCache we currently refresh tokens based on a hardcoded threshold: https://github.com/zalando-incubator/lib-oauth-tooling/blob/master/src/TokenCache.ts#L8, used in https://github.com/zalando-incubator/lib-oauth-tooling/blob/master/src/TokenCache.ts#L96

To be more resilient we should refresh tokens based on the percentage of their lifetime, for example when 50% of the expiration time is met. We should default this value to 50% and provide an option to be able to parameterise this value.

Type definitions serve multiple purposes. One one side, they help the compiler to determine choices depending of context and enrich the development workflow.
On the other side, do they provide documentation for possible consumers and readers.

In terms of #15 and #30, I would like to suggest to enrich the project with valuable type information to promote the usage of this library.

Something like

requireScopesMiddleware(scopes: string[], precedenceFunction:Function) {

where precedenceFunction when returning true will overwrite the normal scope check.
--> This would allow to check for optional scopes that are only allowed when another conidition is met.

TODO

• improve requireScopesMiddleware
• move express related stuff into a seperate file
  • move tests to a separate file

PR will follow.

• Find name (auth-mosphere)
• Update readme
• Update packages.json
• push new version
• Restart versioning at 1.0.0 #92

...to test, lint, publish to npm and create a tag in git.

Currently, this lib can only be used with the Zalando OAuth server since a REALM is accepted in the OAuth config (used in https://github.com/zalando-incubator/lib-oauth-tooling/blob/d222a021d20b2440d3662f0249dd1057fb50c23e/src/oauth-tooling.ts#L155 and https://github.com/zalando-incubator/lib-oauth-tooling/blob/d222a021d20b2440d3662f0249dd1057fb50c23e/src/TokenCache.ts#L44).

It should be removed from the config. For Zalando internal use one should use the queryParameter option proposed in #39

@graviton/... packages cannot be consumed outside Zalando, get rid of them.

Currently you can only pass (user or client) credentials implicitly via the credentialsDir option in the OAuthConfig type. However it may be necessary sometimes to pass such information explicitly via a string. Furthermore, not for all grant types both information are mandatory.

This ticket may be related to #110 depending on the concrete solution.

See the current validation of OAuthConfig: https://github.com/zalando-incubator/authmosphere/blob/master/src/oauth-tooling.ts#L185 resp. https://github.com/zalando-incubator/authmosphere/blob/master/src/utils.ts#L143
See the current solution of reading in the credentials: https://github.com/zalando-incubator/authmosphere/blob/master/src/oauth-tooling.ts#L187

See https://tools.ietf.org/html/rfc6749#section-4.1.1