@gnsharan wrote:
The app should make multiple calls(to authorize, then get the token and then execute the api with the token received) to execute a single api right.
Correct. that is the way it works with OAuth: apps have access to credentials - often a client ID and secret, but there can be other credential types. Apps use those credentials to obtain a token. (Think of the token as another kind of credential - a time-limited credential.) Then, the app makes a request-for-service, passing the token in the request. The service provider validates the token before providing service (= responding to the API call).
You might be wondering: Why is it important to have time-limited credentials? The key reason is that the window of vulnerability for a lost credential is smaller. Recognize that by sending the token across the network, it is somewhat exposed. It becomes vulnerable to leakage or compromise. This can happen because of incautious logging, or tracing, or a TLS 0-day exploit, or a weak cipher, or some other problem. This kind of problem is hard to avoid when sending sensitive data over a potentially hostile network. If the token "leaks", or is disclosed inappropriately, then the malefactor can use the token for the duration of its lifetime. But if the lifetime of the token is just 15 minutes, then there is a very small window of vulnerability. Conversely if you were to send the long-lived app credential in requests for services, there is a similar non-zero likelihood that the app credential will leak, for the same reasons and in the same ways I discussed above. And if that app credential lives for a year, or more, then, malefactors have a much longer time period over which they may fraudulently exploit that credential.
What's the difference? you might wonder. The app credential is still long-lived, right? OAuth tells us to use the app credential as a way to get a short lived credential (token). But the app credential still lives for a long time, and still is subject to compromise, right? That's true, but..(1) the fewer times you transmit a credential over a network, the lower likelihood of network-based compromise. Conversely if you transmit it more frequently, you will have a higher chance of compromise. Sending the app credential ONCE, to get a token that can be used in thousands of requests-for-service, or even tens of thousands of requests, limits the potential exposure of the app credential. and (2), there is no need to send the app credential over the network at all, if you use one of the more clever grant types, such as the one described in IETF RFC 7523 - in which the request-for-token is made via a self-signed payload (signed JWT). And taking that one step further, if the app credential is a private key, then that can be provisioned in the browser itself via WebCrypto, which means it never needs to be transmitted ever, not even during initial provisioning.
You might then ask, why not just use this signature based credential passing idea for every request-for-service? We could abandon the idea of the token, and just always sign requests-for-service in a way similar to what is described in RFC 7523. That would be "secure", but there are downsides. The biggest one is, it would be expensive in terms of time and CPU resource for the service implementation to validate the signature on every inbound request-for-service. If you're processing 10 requests per second and you don't mind 8ms more latency, then it's no problem. But if you are servicing thousands of requests per second, and you care about latency, then you don't want to be validating cryptographic signatures for every request. Better (more efficient, faster) to use an opaque token.
tl;dr: OAuth is a good idea.
LinkedIn
Twitter
