Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Next revision
Previous revision
documentation:latest:webserviceprotection [2019/10/30 15:24]
coudot created
documentation:latest:webserviceprotection [2019/10/30 15:29]
coudot
Line 1: Line 1:
 ====== WebServices / API ====== ====== WebServices / API ======
  
-====== Presentation ​======+===== Presentation =====
  
 WebServices and API are mostly requested by an application,​ and not the end-user itself. In this case, you can not rely on LL::NG standard Handler to protect the webservice, as it will expect a cookie, which is not defined in the application requesting the service. WebServices and API are mostly requested by an application,​ and not the end-user itself. In this case, you can not rely on LL::NG standard Handler to protect the webservice, as it will expect a cookie, which is not defined in the application requesting the service.
Line 7: Line 7:
 LL::NG offers several solutions to protect this kind of service. LL::NG offers several solutions to protect this kind of service.
  
-====== ServiceToken Handler ​======+===== ServiceToken Handler =====
  
 Two Handlers will be used: Two Handlers will be used:
Line 13: Line 13:
   * The backend Handler that will protect the web service, and will consume the token   * The backend Handler that will protect the web service, and will consume the token
  
-See [[servertoserver|ServiceToken Handler documentation]]+See [[servertoserver|ServiceToken Handler documentation]].
  
-====== OAuth2 endpoints ​======+===== OAuth2 endpoints =====
  
 We suppose here that LL::NG is acting as [[idpopenidconnect|OpenID Connect provider]]. The web application will then be able to get an access token from LL::NG. This token could be sent to the webservice that can then validate it against LL::NG OAuth2 endpoints. We suppose here that LL::NG is acting as [[idpopenidconnect|OpenID Connect provider]]. The web application will then be able to get an access token from LL::NG. This token could be sent to the webservice that can then validate it against LL::NG OAuth2 endpoints.
  
-===== UserInfo ​=====+==== UserInfo ====
  
 You can use the UserInfo endpoint, which requires the access token to deliver user attributes. You can use the UserInfo endpoint, which requires the access token to deliver user attributes.
Line 38: Line 38:
 </​file>​ </​file>​
  
-===== Introspection ​=====+==== Introspection ====
  
 Introspection endpoint is defined in [[https://​tools.ietf.org/​html/​rfc7662|RFC 7662]]. It requires an authentication (same as the authentication for the token endpoint) and takes to access token as parameter. Introspection endpoint is defined in [[https://​tools.ietf.org/​html/​rfc7662|RFC 7662]]. It requires an authentication (same as the authentication for the token endpoint) and takes to access token as parameter.
Line 59: Line 59:
 } }
 </​file>​ </​file>​
 +
 +===== OAuth2 Handler =====
 +
 +We also suppose here that LL::NG is acting as [[idpopenidconnect|OpenID Connect provider]]. But the webservice will be protected by the OAuth2 Handler and will just have to read the HTTP headers to know which user is connected.
 +
 +<​code>​
 +curl \
 +   -H "​Authorization:​ Bearer a74d504ec9e784785e70a1da2b95d1d2"​ \
 +   ​https://​oauth2.example.ccom/​rest/​myapi ​
 +</​code>​
 +<file javascript>​
 +{
 +   "​check"​ : "​true",​
 +   "​user"​ : "​coudot"​
 +}
 +</​file>​
 +
 +See [[oauth2handler|OAuth2 Handler documentation]].