There is a security flaw in your process of issuing Access Token via Refresh Token.
SHA256 secret of AppID:AppSecret which is a mandatory parameter required (see Fyers v3 Docs), is NOT being validated by Fyers Auth Server. Here is the screenshot where even if we pass any random text in the appIdHash param, we get a successful access token in response.
Every time a user fetches Access token using Refresh token, the user should receive a NEW Refresh token and the OLDER Refresh token should become INVALID for any further usage. Currently, there is NO protection against REUSE of same Refresh token in a single day. This should protect against malicious user silently using used Refresh token to get access token when legitimate user was already logged in.
There MUST be an API call endpoint / Method in SDK / functionality on Apps Dashboard Webportal to LOG OUT of our custom API apps. Currently, there is NO such way to secure our running APIs incase of any security breach is noticed by legitimate user. Access token remains valid till day end, Refresh token remains valid for 15 days and no one can stop their usage. This is a major security concern that needs to be reviewed !
I would differ on pt 1 & 2, if you consider the whole login flow.
Refresh token is validated with PIN, so if refresh token alone is compromised then how would you get in? if both are compromised, then its going to happen with any login system including banking logins. I dont know if you can brute-force your way with PIN and if they have checks on this.
I prefer the refresh token 15 days validity, without updating after using it.
I agree API log out/invalidation of API should have a process. Also, all logged in tokens should be listed and one can logout/revoke from that list.
All API-key based authentication eventually suffers from this if the key is compromised so its upto user to safeguard it.
Yes @chirag, this will occur if PIN and Refresh token are compromised. To have additional layer of security, Fyers Auth server should** issue** renewed Refresh token and invalidate older refresh token after one-time usage, as a standard practice.
Also, as per current scenario, appIdHash is redundant, with no worth to that param. So, only two out of three layers of security is what we have.
Point 3 is outstanding. We still can not know how many sessions are using our access token(s) currently. We ought to have control over it.
