cloudendpoints / endpoints-java

A Java framework for building RESTful APIs on Google App Engine
Apache License 2.0
32 stars 35 forks source link

openapi.json: oauth2 securityDefinitions 'firebase-##' #158

Open cyraid opened 6 years ago

cyraid commented 6 years ago

For some reason the securityDefinitions of the openapi.json for firebase auth is generating as:

"securityDefinitions": {
  "firebase-115e09da": {
   "type": "oauth2",
   "authorizationUrl": "",
   "flow": "implicit",
   "x-google-issuer": "https://securetoken.google.com/project-id",
   "x-google-jwks_uri": "https://www.googleapis.com/robot/v1/metadata/x509/securetoken@system.gserviceaccount.com",
   "x-google-audiences": "project-id"
  },
  "api_key": {
   "type": "apiKey",
   "name": "key",
   "in": "query"
  }
 },

Why does it generate as "firebase-115e09da"? The developer portal can't detect it's from firebase unless I rename all instances to "firebase".

My @Api is:

@Api(
  name           = "name",
  title          = "Project Title",
  version        = "v1",
  description    = "Project Description",
  apiKeyRequired = AnnotationBoolean.TRUE,
  authenticators = {EspAuthenticator.class},
  clientIds      = {
    Constant.API_EXPLORER_CLIENT_ID
  }, // clientIds //
  namespace = @ApiNamespace(
    ownerDomain = Core.PROJECT_DOMAIN,
    ownerName   = Core.PROJECT_DOMAIN,
    packagePath = ""
  ), // namespace //
  issuers = {
    @ApiIssuer(
      name    = "firebase",
      issuer  = "https://securetoken.google.com/" + Core.PROJECT_ID,
      jwksUri = "https://www.googleapis.com/robot/v1/metadata/x509/securetoken@system.gserviceaccount.com"
    ) // ApiIssuer //
  }, // issuers //
  issuerAudiences = {
    @ApiIssuerAudience(name = "firebase", audiences = Core.PROJECT_ID)
  } // issuerAudiences //
) // Api //
tangiel commented 6 years ago

It's done this way because during config generation, we have no idea of knowing how many auth configs there will be for an issuer config. Each set of target audiences requires a different auth config in OpenAPI. Therefore, we just generate a hash for all of them. We currently don't have any sort of normalization phase, which is where we would go back and eliminate the hash when it's unnecessary. @inklesspen

cyraid commented 6 years ago

You'd have to maybe do a quick scan for each auth name to see if there are duplicates first before making hashes. Would be plausible as it's used as an "offline" app.

tangiel commented 6 years ago

@cyraid this should be fixed in developer portal soon so you don't have to edit your spec.

cyraid commented 6 years ago

Oh, excellent! Thank you for looking into this.