Background: I am using node.js and express to create an API. I have applied OAuth in my API server in a standard consumer / user key / secret fashion (likewise Twitter, Facebook etc). I hope that 3 parties have to be linked to my API, again in the same way as these common APIs.
Generally, a customer will connect to an application token / secret (like, you create a Facebook app as a developer and this is given to you). Although there are times when the client can not provide a secret for the application because the code applies in unsafe format. In particular, I am referring to javascript libraries. For example, developers do not want to reveal their application secretly in JavaScript code because it is plain text and can be read by malicious users.
I have noticed that Facebook has avoided this problem, the developer must provide only one application token (no secret) for the JavaScript library. I do not understand how to provide an alternative to my API that is basically without making my library insecure. That is, if a Javascript client library is being requested without providing a well-protected token / secret to AIT, how are those requests certified by the OAuth API?
Intellectually, the best solution I could think of is to return a secret to the library, via a HTTPS connection to some kind between the Javascript client library and the API server The token of handoff would have. I'm not sure how to protect this handoff to prevent fraud.
Cases It is better to follow the standards to implement certain custom methods. The OAuth2 authorization specifies the grant to flow. The The standard is referred to as: When the token is issued during the entered entry, the grant flow does not certify the client in the authority, in some cases , The client's identity can be verified through the redirection URI used to give the access token to the client. Access tokens can be accessed by the resource owner or other applications with access to the resource owner's user-agent. Indirect grant improves the responsiveness and efficiency of some customers (such as customer in-browser applications) because it reduces the number of rounds needed to obtain an access token. However, this facility should be weighed against the implications of the use of indirect grant, especially when the authorization code grant type is available. There are some security vulnerabilities in this. But as far as I can see, other methods do not work for you, because they are exposing the secrets to the customer (the owner of the third-party website) or the resource owner (user) That's why you should stay with it. / P>
Comments
Post a Comment