I have two sites (web apps) in Azure, written under ASP NET. I want to implement such a scenario: a user registers on one of them and then, being authorized, gets the opportunity to interact with him through the other, i.e. Site 2 receives an "access token" (analogy with the OAuth protocol) from site 1, through which it will be possible to change the state on site 1 and display the result of the operation on site 2.

My question is quite general: how can this be realized, in the direction of which to "dig"? I have no serious experience in writing API, so I get scared when choosing between the OAuth server, the Azure Management API, the Azure API apps. What is the best fit?

  • specify, suitable for what? - Mikhail Vaysman
  • @Mikhail Vaysman to implement the described scenario: a) the ability to authenticate our user through site 1 b) the subsequent opportunity to use site 2 to interact with 1st - Mergasov

1 answer 1

If you need to link only these 2 applications, then you do not need oauth.

  • Arrange an array on each side in the table or in the session memory.
    hash codes.
  • When calling an API, the initiator generates a simple hash code, stashes it (with a timestamp) in an array of hash codes and sends it along with the API request to the interlocutor (the second system).
  • The interlocutor, upon receiving the request, sends the initiator (to the endpoint known to him, and not to the address of the requester) a request for confirmation of the hash code
  • The initiator checks the hash code - searches for it in its array, if it finds — confirms and the code deletes, does not find — does not confirm
  • The interlocutor acts on the basis of the confirmation of the initiator.
  • And if it is possible to provide both systems with static IPs (which is far from always on cloud-based systems), we immediately reject requests from unknown IPs without talking

For complete happiness, to implement the removal of obsolete hash codes - during the next passage of the array of hash codes, delete those for which there was no confirmation request for say 2 minutes.

If there are more than 2 systems, then requests for confirmation of the hash code are sent to all known endpoint.

I am sure that this is easier and more reliable to implement than any system based on a digital signature.

  • I was thinking at all, is it a good practice to allow a third-party application (we will take it out of the brackets, that in this scenario it’s my application trusted) to change the state of my clients? Let them even logged in to this third-party application (through me), and the API client received a token, but nothing will prevent it (the API consumer) from starting to abuse and send me requests on behalf of the client. - Mergasov
  • how do you imagine that? API consumer can only do what the entry point interface and API data schema allows - Eugene Bartosh
  • I can allow this particular application, through a token, say, to change the avatar of a particular user. Nothing will prevent the application to form such a request without the knowledge of the user. Or is it all from the field of paranoia? I just never built such an architecture, so I ask, perhaps, stupid questions - Mergasov
  • are we preparing for the uprising of cars? :-) - Eugene Bartosh February
  • The scenario I described is actually controversial, I wanted to throw a fresh idea :-) if accessing the API between systems is supposed to be very intensive - then you need to follow the classical path - exchange of secret keys, generating an open token with its subsequent verification on the side of the API - a digital signature that is - Eugene Bartosh February