-
Notifications
You must be signed in to change notification settings - Fork 27
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
Comments
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. |
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 |
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'. |
I don't think this is for us to define. Maybe some recommendations as @ahokkonen says above. |
2023-03-09: @cookeac to look into documenting just this. |
Should we include a standard for authentication?
The text was updated successfully, but these errors were encountered: