Is this token authorization scheme secure?

Question

I have Web application, name it A, from which user should be able to login to another one B (developed by other company) without typing any logins/passwords.

We have thought up following scheme:

• We generate random secret ID for each user in database
• Secret ID is regenerated after login into A
• We save usernames for system B in our system for each user
• When user is logged into A and wants to open B, system A sends username and secret ID to system B over HTTPS, B, before answering request, sends those back to A, which checks if secret ID is correct, regenerated it and sends back to B whether it was correct; B, if got positive response, logs user in and sends session ID to A

Does this scheme have any flaws?

Answer 1

It sounds like you could benefit from a separate authorization server that all of your applications can depend upon.
In the long run it will probably be easier to make authentication/authorization a cross-cutting concern instead of copying users from on application to another.

OpenId Connect could be appropriate; it builds on top of OAuth2.

These might not be the flaws you are looking for, but consider these separate situations:

• 3 new system C, D, and E are introduced into the organization and users need to login into all of them
• A new requirements arises for System B to call an HTTP API, System F, as the current user
• A user is removed from System A
• System A is decomissioned, but system B has become critical to the business
• A user opens B directly, without going through A
• Regenerating all the secret keys might cause unnecessary load on network/systems
• The consultant company developing System B has to learn your custom authentication method
• New team members have to learn your home grown authentication protocol instead of an industry standard
• Having gained access to System A, an attacker also gets access to System B.

What you have described does not sound like token based authentication IMO. In token based authentication the username and password are exchanged for a token, which would be presented to System A with each request.
At a high level this is how I understand token based authentication to work:

• Unauthenticated user browses to System A
• System A redirects the users' browser to System Z, the authentication provider
• The user enters her credentials into System Z
• System Z redirects the user's browser back to System A, with a token
• All subsequent requests from the user's browser to System A include the token
• System A trusts tokens issued by System Z

Note that the user does not enter her credentials into System A.

The above steps are over-simplified; they do not include token expiry or refresh tokens. I have described the most simple OAuth2 authorization flow (implicit flow); the more common is the "Authorization Code Flow".
The Implicit Flow is suited to JavaScript clients, while the Authorization Code flow is suited to server based applications.
There is a lot of good information online on OAuth2 and OpenID Connect.