A WaveMaker application can have different services like Database, REST, SOAP, and all these services have API endpoints that are automatically generated by WaveMaker when they are created. So the application can act as a resource-serving microservice and these APIs can be used by other microservices/applications.
These API endpoints are automatically used by the WaveMaker application UI when they are bound to a variable. If the application is secured with a security provider the existing architecture of the WaveMaker app UI already handles the authentication of the APIs i.e., if the UI and services are in the same application.
The WaveMaker application APIs can also be invoked from different clients. To know more about What is Client.
How can WaveMaker application APIs be used in other clients?
The WaveMaker application APIs that are exposed can be used in many ways and if the client is,
- A WaveMaker application then the APIs can be imported as a REST service or as Swagger.
- A Non-WaveMaker application then the APIs can be invoked by making an HTTP request to the API.
When WaveMaker APIs are secured with security providers
APIs exposed by the application are also secured and require authentication to access them when used in other applications.
If the application is secured by any form-based security provider like Database/LDAP/DB/Custom Security, then the client can pass the BASIC authorization header in the HTTP request to invoke the application APIs. Basic authentication has to be enabled to access the APIs and in WaveMaker, by default, basic authentication is enabled for form-based authentication providers.
If the application is secured with an SSO security provider like OpenID, SAML, CAS, then the below approach can be used to invoke the secure APIs.
How can Clients invoke WaveMaker Application APIs Secured with SSO?
If a client that needs to invoke the WaveMaker application APIs has security configured, the same user context cannot be used to access the WaveMaker secured APIs as the security configured can be different, even if it is the same security provider there cannot be common user context between them.
This can now be achieved in WaveMaker by using JWS or Opaque tokens as the secondary authentication providers. In other words, if the WaveMaker application's APIs are secured and are to be used by other clients then, the user can enable a secondary authentication provider i.e., JWS or Opaque providers. This makes the APIs accept a token and provide user access to the APIs.
For example, consider a client and one WaveMaker application, the application provides some services and has the primary security SAML configured. If the service APIs are to be accessed from the same application UI then the existing architecture of the WaveMaker applications takes care of the complete flow. In this flow, the user is redirected to the SAML server for authentication and once the user is authenticated, they get redirected to the application.
If the same APIs are invoked from a different client, then along with SAML a secondary security provider needs to be configured. Now the client can invoke the API with a bearer token header in the request and gain access to the APIs. To know more about Bearer token.
What is Client
The client can be a WaveMaker application/Non-WaveMaker application, microservice, Java client, command line, Postman, and so on. The client should have a token of the current user, making the request that is issued by any provider that follows OpenID specification. According to the OpenID specification, the provider returns two tokens, an ID and an access token. Any one of the tokens can be passed in the request as a header while invoking the API.
The OpenID provider from which the client obtained the token needs to be configured as the secondary security provider in the resource server i.e., the application which has the APIs.
What is Authorization Server
An authorization server issues tokens to clients that can be used to access protected resources on the resource server which is known as bearer token. These tokens are usually in the form of OAuth2 ID and access tokens and are issued after the client has been authenticated and authorized by the authorization server. The authorization server is responsible for ensuring that only authorized clients can access protected resources on the resource server.
What is Resource Server
The resource server is the WaveMaker application which has the service APIs exposed for use. These APIs are secured by the primary security provider but if we enable a secondary security provider that can be one of JWS or Opaque and thus it can accept ID or access token in the request which is being made by the client and provide access to the client. The resource server handles the validation of the ID/Access token. To know more about the differences between an ID token and an Access token, see ID/Access token .
If the token is an ID token, configure the JWS provider, and if it is an access token configure the Opaque provider in the resource server as a secondary provider. This is because the ID token can be validated directly by the resource server but the access token needs to be verified using an introspection endpoint provided by the authorization server.
Configuring WaveMaker Application as Resource Server
WaveMaker application can be configured to accept an ID token or access token as bearer token in the authorization header. It is then validated using the JWS provider if it is an ID token or using Opaque token provider if it is an opaque access token.
This makes the application a resource server that validates ID and access tokens to share resources. To know how to configure JWS or opaque as secondary authentication providers, see Configure JWS and Opaque providers.
Configuring WaveMaker Application as Client
WaveMaker application can be configured as a client to pass the ID or access token to the resource server. To know more, see How to Pass Logged-In User ID/Access Tokens as Header.