I've seen many SPAs with totally unauthenticated API endpoints. They'll control what a user's allowed to do with the UI and hide unauthorized functionality, but direct requests to the backend still allow any request.
The thing to keep in mind is: don't trust the client. The final word on authentication and authorization should always be done server-side.
Unfortunately, I believe you may have missed the point of this library and blog post. It merely simplifies the developers life when implementing the client side flows and interactions associated with authorization with one or more auth providers.
This does not preclude proper API authorization or loading sensitive modules post authorization from an authorized end-point.
As someone who has implement many very related flows, I am glad to see an effort to unify, share and simplify this experience.
I'm currently trying to find a way to only download the modules only if the user has the proper authentication and then load them into the already bootstrapped angular, but it isn't easy.
You shouldn't be concerned about someone having all of your client-side source code; the worst they could do with it is clone your site and make a bad, hacky reverse engineered attempt at emulating your backend API.
If you think hiding your application structure or references to API endpoints secures you, then you're doing something very wrong.
This isn't 'client side authorisation' in the sense you are talking of.
Specifically it still relies on a /session route which only accepts valid authorization objects which can be though of as keys in a more 'traditional' 'server side authentication' approach.
Surprisingly, its the only one service I could find in the space that supports email login. There's lots of providers for social login, but as far as i can tell DC is the only one doing email.
Based on the pricing page (https://www.authic.com/pricing), it looks like you're capped at 100 paying users. Is that right?
I have always found it difficult to keep monitor HN for responses to my comments!
It's so much easier if the request can contain an auth header/parameter pointing to a long-term API key or equivalent.
Torii's providers are designed to be re-usable without the session manager though, and they work just great with Simple Auth. Check this out: https://github.com/Vestorly/torii/blob/master/example/simple...
State happens in the client, requests to the backend come with pre-conditions.
It's an auth session, which is orthogonal (and transparent) to the REST api (e.g with cookies).