Is it possible to use a social provider like Microsoft, Google,… and a custom database or something else…
This will return a valid token. That’s all ok. But if you have a paid service. Like that people need to pay €5 a year to use your service.
Is it possible to check that also during the login procedure (Information can be stored in a database with the email and “Paid” status fields)? Or do you have other options to get this functionality?
So the thing is I will have an API that will do different stuff. And also a client APP.
You can only call that API with that email. And if you paid your annual service fee…
If I understood your requirement correctly you want to support a few different ways of end-user authentication, but you also want to ensure that the end-user completing the authentication has a valid subscription to your service.
You can use the concept of custom rules to implement such validation. A rule will run after the end-user completed an initial authentication process (for example Google social authentication or a custom username and password) so by the time the rule is called you already know who the user is. At this time you can then perform a call (likely through HTTP) to an external system that will confirm if the user has an active subscription; if it does, you let the authentication complete, if it doesn’t you reject the authentication request.
Have in mind that the above completely rejects the authentication request; in some situations you may still want to let the users access the application and only then at the application level you inform them that they do not have an active subscription and as such cannot really do anything useful. However, if you really want to immediately abort the authentication process then you can use a rule to achieve that (rules are just Javascript code that run as part of the authentication pipeline so they are pretty flexible; see the reference documentation for additional information).
@jmangelo And how should you solve it if you let the user access the application and show a message that you need a subscription.
Thing is, I have a client application (No idea yet what technology) that will call an API. In the API I will do some specific stuff.
I want to prevent that people can call my API directly without my own “Client Application” and also that they need a subscription to use my service.
@jmangelo And how should you solve it if you let the user access the application and show a message that you need a subscription.
Thing is, I have a client application (No idea yet what technology) that will call an API. In the API I will do some specific stuff.
I want to prevent that people can call my API directly without my own “Client Application” and also that they need a subscription to use my service.
Preventing that no one calls the API directly may be complex; if for example you choose to implement a SPA, then the SPA will need to call the API, but there will be no way for SPA to prove it’s the SPA calling so in this case the only thing you can ensure is that the call is coming from an authorized user.
In relation to handling this outside a rule, it depends. The rule could still include the subscription status on the issued tokens. This would not block the actual authentication, but then the application or API would react accordingly depending on the subscription status.
So the best way to do it is with the rules…