Support of non JWTs (JSON Web Tokens), additional authorization params & TS-wrapper about client-js

[jmandel]

Thanks for the comments here!

I've captured your first point in #28 -- this is a bug introduced in a recent contribution and we should fix it.

Re: communicating a client id, it's true that the OAuth spec allows it to appear optionally; the SMART spec says something more specific, since it's a profile on OAuth designed to ensure more consistent behavior:

Hope this makes sense!

Re: typescript, we aren't currently working on this but would love contributions in this direction. (Overall, it's getting to be time for a ground-up rewrite...)

[ies1]

Thanks for the quick answer and for opening the issue!

To the client_id:
Our server is designed for "public apps". He is more like an EPR than an EHR, where the patients can store personal health-related data from third party apps (like Smartphone apps) and share the data for clinical trials. Therefore, the client id will never be optional.
Now the OAuth sever expects the client_id to be always in the request body and not only when no client_secret is set. Atm. most of these developed "public apps" have a secret.

With the doc part above the table you've posted, I now know, that we should not send / define client_secrets for such public apps. So as far as I understand, we should deactivate / delete the secrets of these apps.

Do I understand this correctly?

---

TypeScript: I'll send you a PM next week for some discussion and contributions on this point.

[jmandel]

It's correct that if you're only supporting public apps, then there should be no client_secrets involved.