Authorization (lock symbol) is rendered incorrectly

I have endpoints that either have a required authorization or an optional authorization (see example). I think the lock symbols are rendered incorrectly. It shows a black locked symbol for optional authorization (/public) and and a gray unlocked symbol for required authorization (/private).

Q	A
Bug or feature request?	Bug
Which Swagger/OpenAPI version?	3.0.0 and 2.0
Which Swagger-UI version?	3.x currently used by hosted Swagger Editor + master branch (03.04.2018 15:36)
How did you install Swagger-UI?	Hosted Swagger Editor + locally using master branch (03.04.2018 15:36)
Which browser & version?	Chrome 65.0.3325.181
Which operating system?	Windows 10

Demonstration API definition

openapi: 3.0.0
servers:
  - url: 'https://localhost/api/'
info:
  title: OpenEO API
  version: 0.3.0
paths:
  /public:
    get:
      summary: This endpoint allows users to access it with AND without authentication.
      security:
        - {}
        - Bearer: []
      responses:
        '200':
          description: ...
  /private:
    get:
      summary: This endpoint allows users to access it only with authentication.
      security:
        - Bearer: []
      responses:
        '200':
          description: ...
components:
  securitySchemes:
    Bearer:
      type: http
      scheme: bearer

Expected Behavior

It shows a gray unlocked symbol for optional authorization (/public) and and a black locked symbol for required authorization (/private).

Current Behavior

It shows a black locked symbol for optional authorization (/public) and and a gray unlocked symbol for required authorization (/private).

[webron]

I understand the confusion, but it’s actually working as expected.

When a user fills the authorization, the lock becomes closed and black - that indicates that there’s security information provided. An unlocked lock, means that the user has not provided the information. We’ve had discussions in the past about how some people expect it to be one way and some the other. We’ll consider changing it altogether to make it clearer.

In your case, it behaves as expected (in our intent) - since you allow a no-security option, meaning the user can use the call without providing credentials, the lock is black and locked indicating you can execute the call.

[bmbell]

I found the current implementation very confusing. Just take a real-life scenario - if something is locked (in this case, the black lock symbol), then it generally means it cannot be accessed without a key (e.g. an api key). The key “unlocks” the service, and grants access to it. Thus, the open lock symbol would be shown after credentials were entered.