feat: add Api docs

docs/admin/configuration/authentication-and-user-management/keycloak.md

@@ -307,7 +307,7 @@ IDP_DOMAIN=your-idp-domain.example.com
 IDP_ACCOUNT_URL=https://your-idp-domain.example.com/realms/openCloud/account
 ```
 
-The Docker Compose file `idm/external-idp.yml` contains the complete configuration for each opencloud component. The file `10_opencloud_ldap_schema.ldif` contains the OpenCloud LDAP schema and is loaded during the startup of the OpenLdap container. In this mode, your IdP setup is not part of the openCloud Deployment.
+The Docker Compose file `idm/external-idp.yml` contains the complete configuration for each OpenCloud component. The file `10_opencloud_ldap_schema.ldif` contains the OpenCloud LDAP schema and is loaded during the startup of the OpenLdap container. In this mode, your IdP setup is not part of the OpenCloud Deployment.
 
 :::warning
 

docs/dev/server/Apis/_category_.json

@@ -0,0 +1,4 @@
+{
+  "label": "Apis",
+  "position": 1
+}

docs/dev/server/Apis/grpc_apis/index.md

@@ -0,0 +1,52 @@
+---
+title: gRPC
+sidebar_position: 2
+---
+
+## **R**emote   **P**rocedure   **C**alls
+
+[gRPC](https://grpc.io) is a modern open source high performance Remote Procedure Call (RPC) framework that can run in any environment. It can efficiently connect services in and across data centers with pluggable support for load balancing, tracing, health checking and authentication. It is also applicable in last mile of distributed computing to connect devices, mobile applications and browsers to backend services.
+
+## Advantages of gRPC
+
+### 🚀 Performance
+
+gRPC uses http/2 by default and is faster than REST. When using protocol buffers for encoding, the information comes on and off the wire much faster than JSON. Latency is an important factor in distributed systems. JSON encoding creates a noticeable factor of latency. For distributed systems and high data loads, gRPC can actually make an important difference. Other than that, gRPC supports multiple calls via the same channel and the connections are bidirectional. A single connection can transmit requests and responses at the same time. gRPC keeps connections open to reuse the same connection again which prevents latency and saves bandwidth.
+
+### 🛡️ Robustness
+
+gRPC empowers better relationships between clients and servers. The rules of communication are strictly enforced. That is not the case in REST calls, where the client and the server can send and receive anything they like and hopefully the other end understands what to do with it. In gRPC, to make changes to the communication, both client and server need to change accordingly. This prevents mistakes specially in microservice architectures.
+
+### 🔍 Debuggability
+
+gRPC requests are re-using the same context and can be tracked or traced across multiple service boundaries.
+This helps to identify slow calls and see what is causing delays. It is possible to cancel requests which cancels
+them on all involved services.
+
+### 📦 Microservices
+
+gRPC has been evolving and has become the best option for communication between microservices because of its unmatched
+performance and its polyglot nature. One of the biggest strengths of microservices is the freedom of programming
+languages and technologies. By using gRPC we can leverage all the advantages of strictly enforced communication
+standards combined with freedom of choice between different programming languages - whichever would fit best.
+
+:::info gRPC Advantages
+
+- http/2
+- protocol buffers
+- reusable connections
+- multi language support
+
+:::
+
+## CS3 APIs
+
+![CS3 Organization](/img/cs3org.png)
+
+The [CS3 APIs](https://github.com/cs3org/cs3apis) connect storages and application providers.
+
+The CS3 APIs follow Google and Uber API design guidelines, specially on error handling and naming convention. You can read more about these
+guidelines at [Google Api Design](https://cloud.google.com/apis/design) and [Uber Protocol](https://github.com/uber/prototool/blob/dev/style/README.md).
+
+The CS3 APIs use [Protocol Buffers version 3 (proto3)](https://github.com/protocolbuffers/protobuf) as their
+Interface Definition Language (IDL) to define the API interface and the structure of the payload messages.

docs/dev/server/Apis/http/authorization.md

@@ -0,0 +1,142 @@
+---
+title: Authorization
+sidebar_position: 40
+---
+
+In its default configuration, OpenCloud supports three authentication methods as outlined on the [OIDC official site](https://openid.net/specs/openid-connect-core-1_0.html#rfc.section.3):
+
+1. Authorization Code Flow
+2. Implicit Flow
+3. Hybrid Flow
+
+For detailed information on OpenCloud's support for OpenID Connect (OIDC), please consult the [Official Documentation](../../../../admin/configuration/authentication-and-user-management).
+
+While selecting an OpenCloud client for authentication, take note of specific limitations such as the `Redirect URI`:
+
+| Source  | Redirect URI                                 |
+| ------- | -------------------------------------------- |
+| Android | oc://android.opencloud.eu                    |
+| iOS     | oc://ios.opencloud.eu                        |
+| Desktop | `http://127.0.0.1` <br /> `http://localhost` |
+
+In this example, the desktop app's `client_id` are being used.
+
+```bash
+client_id=OpenCloudDesktop
+```
+
+## Authorization Code Flow
+
+1. Requesting authorization
+
+   To initiate the OIDC Code Flow, you can use tools like curl and a web browser.
+   The user should be directed to a URL to authenticate and give their consent (bypassing consent is against the standard):
+
+   ```plaintext
+   https://cloud.opencloud.test/signin/v1/identifier/_/authorize?client_id=client_id&scope=openid+profile+email+offline_access&response_type=code&redirect_uri=http://path-to-redirect-uri
+   ```
+
+   After a successful authentication, the browser will redirect to a URL that looks like this:
+
+   ```plaintext
+   http://path-to-redirect-uri?code=mfWsjEL0mc8gx0ftF9LFkGb__uFykaBw&scope=openid%20profile%20email%20offline_access&session_state=32b08dd...&state=
+   ```
+
+   For the next step extract the code from the URL.
+
+   In the above example,
+   the code is `mfWsjEL0mc8gx0ftF9LFkGb__uFykaBw`
+
+2. Requesting an access token
+
+   The next step in the OIDC Code Flow involves an HTTP POST request
+   to the token endpoint of the **OpenCloud Identity Server**.
+
+   ```bash
+   curl -vk -X POST https://cloud.opencloud.test/konnect/v1/token \
+   -d "grant_type=authorization_code" \
+   -d "code=3a3PTcO-WWXfN3l1mDN4u7G5PzWFxatU" \
+   -d "redirect_uri=http:path-to-redirect-uri" \
+   -d "client_id=client_id"
+   ```
+
+   Response looks like this:
+
+   ```json
+   {
+     "access_token": "eyJhbGciOid...",
+     "token_type": "Bearer",
+     "id_token": "eyJhbGciOi...",
+     "refresh_token": "eyJhbGciOiJ...",
+     "expires_in": 300
+   }
+   ```
+
+3. Refreshing an access token
+
+   If the access token has expired, you can get a new one using the refresh token.
+
+   ```bash
+   curl -vk -X POST https://cloud.opencloud.test/konnect/v1/token \
+   -d "grant_type=refresh_token" \
+   -d "refresh_token=eyJhbGciOiJ..." \
+   -d "redirect_uri=http://path-to-redirect-uri" \
+   -d "client_id=client_id"
+   ```
+
+   Response looks like this:
+
+   ```json
+   {
+     "access_token": "eyJhbGciOi...",
+     "token_type": "Bearer",
+     "expires_in": 300
+   }
+   ```
+
+## Implicit Code Flow
+
+When using the implicit flow, tokens are provided in a URI fragment of the redirect URL.
+Valid values for the `response_type` request parameter are:
+
+- token
+- id_token token
+
+:::warning Important Warning
+If you are using the implicit flow, `nonce` parameter is required in the initial `/authorize` request.
+`nonce=pL3UkpAQPZ8bTMGYOmxHY/dQABin8yrqipZ7iN0PY18=`
+
+bash command to generate cryptographically random value
+
+```bash
+openssl rand -base64 32
+```
+
+:::
+The user should be directed to a URL to authenticate and give their consent (bypassing consent is against the standard):
+
+```bash
+https://cloud.opencloud.test/signin/v1/identifier/_/authorize?client_id=client_id&scope=openid+profile+email+offline_access&response_type=id_token+token&redirect_uri=http://path-to-redirect-uri&nonce=pL3UkpAQPZ8bTMGYOmxHY/dQABin8yrqipZ7iN0PY18=
+```
+
+After a successful authentication, the browser will redirect to a URL that looks like this:
+
+```bash
+http://path-to-redirect-uri#access_token=eyJhbGciOiJQUzI...&expires_in=300&id_token=eyJhbGciOiJ...&scope=email%20openid%20profile&session_state=c8a1019f5e054d...&state=&token_type=Bearer
+```
+
+For the next step, extract the access_token from the URL.
+
+```bash
+access_token = 'eyJhbGciOiJQ...'
+```
+
+## Hybrid Flow
+
+The Hybrid Flow in OpenID Connect melds features from both the Implicit and Authorization Code flows. It allows clients to directly retrieve certain tokens from the Authorization Endpoint, yet also offers the option to acquire additional tokens from the Token Endpoint.
+
+The Authorization Server redirects back to the client with appropriate parameters in the response, based on the value of the response_type request parameter:
+
+- code token
+- code id_token
+- code id_token token