Implicit OAuth Workflow
The DS Server Angular components implement an integrated, implicit OAuth security handling. In case, the client ID and client secret is passed as a property to the view, the component takes care of the complete OAuth workflow to request a valid access token.
The following diagram shows the client credentials workflow that connects the client DocumentEditor directly with DS Server by sending the client credentials to DS Server to retrieve a valid access token:
Using Access Tokens
The disadvantage of the above method is that the client credentials are exposed client-side. To avoid that, the components can be authorized directly with an access token:
The next diagram shows the authorization with an access token that has been acquired by a server application in between:
In order to retrieve the access token from the DS Server Web API endpoints, a server-side process is required. In this case, the credentials are securely stored on the server and the client will only see the used access token.
To demonstrate this process, an ASP.NET Core web application is used to provide a Web API that requests the OAuth access tokens from DS Server in order to return a valid access token. This endpoint is then called by Angular before the view component is rendered.
The following code shows the implementation of the Web API method AccessToken:
In the Angular application, a service is implemented to call the Web API and to return the access token:
The service implements a resolve() method that is invoked when the navigation starts. The router waits for the data to be resolved before the route is finally activated. This must be defined in the imports section of the app.module.ts:
In the home.component.ts, the result of this attached service is passed to the property _accessToken:
This _accessToken is then used directly in the home.component.html:
Is this Safe?
The positive of the above method is that the client credentials are not exposed client-side. But the security problem is now shifted to the server as the Web API is exposed and could be accessed by other requests. In order to avoid that, the Web API should be secured. For example by using one of the following concepts:
- CORS: Enable only specific hosts.
- Security Middleware: Filter requests (used in this demo).
- Another Authorization: Use second authorization (login) for the Web API.
You can test this method by downloading the sample from our GitHub repository. Let us know, if you have any questions.