I’m working on a custom developer portal that’s not backed by tyk-dashboard/portal templates. So, it’s a separate process, developed within the React ecosystem.
My question is about authentication implementation and maybe all APIs of TYK in general. Many features (listing the catalog items, providing forms to request keys, login, register, and so on) were rather easy to implement when I was using built-in templates that came in tyk-dashboard/portal. However, now, I am not sure how they should be implemented as I feel somewhat lost in the docs. If we particularly talk about the login action, the closest endpoint I could find to what I need is /api/portal/developers/verify_credentials. However, I feel conflicted with that endpoint due to the following thoughts in my mind;
It only responds with “OK” or “Unauthorised” without providing any token that can be used on behalf of the verified developer. So, I understand that this is only for the verification of the provided credentials. That cannot be consumed for any further purposes. So, to my understanding, there is no endpoint to provide this functionality to a fully custom portal? Or, I must have overlooked it.
It requires an authorization header in the request, which is stated as TYK_API_KEY in many places. However, I couldn’t figure out what it should be in the end.
Maybe some straight questions;
What is TYK_API_KEY? How can I retrieve it? I’m curious if it’s a dashboard user’s API key or so? It does not sound like a key that I can publicly use in the network requests on the browser level.
I need many endpoints to achieve what tyk-dashboard/portal is achieving out of the box. I see “TYK APIS” sections on the docs could be beneficial to me. However, I’m not satisfied with how the APIs and their endpoints are demonstrated as it seems none of them can be publicly consumed.
Also note that at the moment it requires a small microservices which handle communication with the dashboard. E.g. you can’t just simply put Reac on top of Dash APIs, since as you mentioned there will be a dependency on API token, which can’t be exposed to public. API token can be obtained as described here //tyk.io/docs/tyk-developer-portal/tyk-portal-classic/customise/custom-developer-portal/
Thanks for your answer. I have seen the two pages you mentioned in your answer. However, they do not satisfy the need up to my expectation honestly.
For example, let’s take the “log-in” feature as a sample. I don’t see such an endpoint in any API? The closest is “/api/portal/developers/verify_credentials” and it does not provide any token or so. It implies we will have to manage tokens for the developer accounts which sound unnecessary while having Tyk and its portal in place already. Isn’t it possible to have Tyk manage tokens and provide an authentication mechanism within its current capabilities?
I think you are missing a point here.
The basic idea that you still leverage all the Dashboard APIs, e.g. key requests, developer management and etc. Login process looks like this:
You send login requests to your microservice (which acts as layer between your user and Tyk Dashboard APIs).
If that’s the only way provided, then I get it. We can tackle the rest. I was hoping to have an API that’s publicly consumable from the beginning. However, it seems that’s not there. I wonder if that happens to be in your roadmap or so?
Basically Portal itself does not have a public API right now. It is a classical web app.
So in order to solve this issue, we will need to add a new set of Portal APIs that can be consumed publicly. Additionally, we working on things like theming and alternative templating, so in future it will be possible to switch between HTML version and for example, our own reference React implementation.