I have a question on how auth.aptible.com works and how dashboard auths with it:
As I understand it, its not OAuth - Implicit Grant based, as the dashboard.aptible doesn’t redirect to auth.aptible for user login. Instead of that - dashboard.aptible.com just posts user credentials to auth.aptible.com which responds with a CORS header for dashboard.aptible.com. Since CORS mentions dashboard it can be trusted. Is that right?
I was wondering if my understanding is correct there. And if there is any other security auth magic happening on that front.
Our CORS domains are whitelisted to just dashboard.aptible.com; no CSRF. For added detail,
the underlying auth.aptible.com uses OAuth to issue grants (the “credentials” sent to auth/api from Dashboard are actually JWT bearer tokens), so for an external/third party integration, we’d use the Authorization Code Flow of OAuth 2.0
While auth.aptible.com is the only service which creates tokens, api.aptible.com (and our other API services), all process and validate those tokens
We use this library to generate bearer tokens that are signed by auth.aptible.com and can be verified by any unprivileged party using auth’s published public key: https://github.com/aptible/fridge
Our API is public, but not well-documented, or quite 1.0 yet — if you’re looking into an integration, let us know and we can figure out a way to make that work.
They are still fully OAuth 2.0-compatible. the difference is that by default, bearer tokens in OAuth 2.0 can be “opaque”, i.e., not containing any information apart from the (usually random) token string. with our approach, the tokens actually contain a bunch of information: the token issuer, subject, scope, expiry, etc.