Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Authentication #68

Open
henning-winkelmann opened this issue Feb 13, 2020 · 5 comments
Open

Authentication #68

henning-winkelmann opened this issue Feb 13, 2020 · 5 comments
Assignees
Labels
next-major-release Confirms that an issue has been deferred until the next major version release.

Comments

@henning-winkelmann
Copy link
Contributor

Should we include a standard for authentication?

@alamers
Copy link
Collaborator

alamers commented Feb 14, 2020

I would think so, but probably as a 'third layer' in the spec? We now have the messages, and an example/suggested url scheme. On top of that we could add a suggested authentication scheme (e.g. OAuth2 / OpenID Connect). Not sure how much we can spec that since often permissions/roles are quite tied to an application.

@ahokkonen
Copy link
Contributor

ahokkonen commented Feb 14, 2020

We could give recommendation that it should be token -based and be passed in request header (Authorization -header) in format "{scheme} {token}" or "{token}", without any strict rule on protocol - OAuth2/OIDC/Basic/else

@alamers
Copy link
Collaborator

alamers commented Feb 28, 2020

If we are considering it as a 'third layer', meaning that it is on-top-of an url-scheme, I don't think we need to specify anything: all of the mentioned protocols are simply add-ons. If we would like to express an opinion on authentication, we should then go a step further and simply state use OAuth2/OIDC. (Basic auth is imho not something that we should recommend).

Note that the message definitions should also be able to be used in other transports, e.g. message queues. There, authentication may be different. Hence my mentioning of a 'third layer'.

@alamers alamers added the next-major-release Confirms that an issue has been deferred until the next major version release. label Sep 9, 2021
@gra-moore
Copy link
Collaborator

I don't think this is for us to define. Maybe some recommendations as @ahokkonen says above.

@cookeac
Copy link
Collaborator

cookeac commented Mar 9, 2023

2023-03-09:
The group revisited this and decided to capture Anton and Arjan's comments above in the Wiki and/or Readme.
#68 (comment)
#68 (comment)

@cookeac to look into documenting just this.

@cookeac cookeac self-assigned this Mar 9, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
next-major-release Confirms that an issue has been deferred until the next major version release.
Projects
None yet
Development

No branches or pull requests

5 participants