Please explain me what is use of Applications table in OpenIddict. I am following this awesome tutorial http://capesean.co.za/blog/asp-net-5-jwt-tokens/ It works perfectly. I have misunderstanding of functions of Applications table which was added for OpenIddict.
Currently, my Front end (Angularjs) + Back end (Web.API with ASP.NET Core and OpenIddict) work fine on one server. The Front end receives tokens and uses it in requests. The Back end generates tokens and evaluate them. All good, but Applications table does not have any records.
Thanks.
The Applications table contains the OAuth2 client applications that are allowed to use your identity server.
Adding a new entry is mandatory when using interactive flows like authorization code or implicit, as client applications have to send a valid client_id: OpenIddict will reject the authorization request if the client_id is missing or doesn't correspond to an application you fully trust (i.e an application stored in the Applications table).
The same rule applies to the client credentials grant, that also requires a valid client_id.
In contrast, there's one case where sending a client_id is not mandatory: when using the resource owner password credentials grant, as demonstrated in the blog post you mentioned.
The specification explicitly states that a client application making a token request MAY send its client_id, which means that this parameter is not mandatory.
A client MAY use the "client_id" request parameter to identify itself when sending requests to the token endpoint.
When no client_id can be extracted from the token request, OpenIddict has no way to determine the identity of the application. In this case, the client_id-related checks are skipped and the request is processed without using the Applications table. That's why your application works without having to populate the Applications table.
Though useful for logging purposes, sending a client_id doesn't make grant_type=password requests safer, as everybody can impersonate an application by re-using the same client_id, unless the application was declared as confidential and was assigned client credentials (read "server-side apps only"). In this case, a malicious caller cannot send a valid token request without knowing the client_secret.
In OpenIddict, there's also one case where adding an explicit app registration is useful: when using the introspection middleware to validate access tokens (instead of the JWT bearer middleware).
As required by the specification, callers must authenticate to use the introspection endpoint: if OpenIddict can't find a corresponding entry in the Applications table, the request will be rejected and the introspection middleware will never work.