- 최신
- 최다 투표
- 가장 많은 댓글
The first clarification point is why do you need login pages for server-side authentication? server-side means machine to machine authentication so there is no login forms that expect end-user input.
If this is the case, then using client credentials authentication flow is the recommended approach. In this case, client application will use app-client id and secret to authenticate (using secured back channel, no browser in this case), after authentication, client app gets accessToken and client should pass this access token to backend (Chorus) with every call. This token shouldn't be exposed to end-user.
You also mentioned "Examples all use a client-side only flow, resulting in a token in the browser". there are multiple authentication flows with OAuth2, the one that returns token to browser is "implicit grant" which is not recommended unless you can't use the recommended one "Authorization code grant". in Authorization code grant, client receives a code instead of the token which could be passed to Token endpoint through secured back channel (not the browser) to get tokens. take a look at this blog post for more details about authentication flows.
I think you might need a specreq to discuss customer's use-case and get advise on which auth flow to use and how.
