I understand the basics of oauth, and I've used it in application before, but never like this.
I've got an oauth2 based api I wrote, and I'm writing a javascript application (in backbone.js), and I want to access the api with it.
My problem is that I need to obtain an access token for the js app. Normally I'd request a token with something like example.com/oauth2/token?client_id=<client-id>&client_secret=<client-secret>&....
If my client secret is supposed to be, well, secret, should I be putting it in my application js?
What's the proper way to do oauth2 over javascript?
My users/app is also the "source" for oauth, so I'm not going to be doing any kind of 3rd party user authentication, as they'll already be logged into the site.
I think you should obtain the access token from the server. This way, your client secret is kept secret on the server. In other words, your server will serve as a proxy for the OAuth exchange.
Related
So, I was looking at building a JS based front-end (probably with Vue.js) when I encountered a problem.
The backend already has OAuth based APIs, where I would need to authenticate all the API calls using an access token. So I went looking for ways to do so and found out that I should use Client Credentials grant.
The problem is that a frontend application would expose the client ID and secret. These can simply be tracked through the "Network" tab of the Browser's inspector. This makes it possible for anyone to obtain an access token and make dangerous API calls (like deleting stuff).
I also found that PKCE flows dont use client secrets.
However, I have 2 problems with PKCE as well:
Authorization is not needed for these APIs to call as these are very adminy (like user management) APIs.
PKCE will also expose the client ID.
Assuming that my understanding is correct, how should I implement the OAuth APIs such that it is secure and does not expose any credentials?
Also, if there needs to be more information, please let me know.
I have designed a simple HTML/CSS and JS/jQuery application, and now it's the moment of authentication integration. On the server side, I have done a REST API which allows clients to get some data. But, now I want to authenticate each request with access and/or session token.
I read many websites to find agreements or advice to establish security between the client (JS) and the REST API (PHP), but unfortunately I found nothing or not interesting.
So I ask you to enlighten me (if you want) to know what to do, what to implement, conventions, etc.
What I read:
Designing a Secure REST (Web) API without OAuth
Token Based Authentication for Single Page Apps (SPAs)
I cannot post more links according to my reputation...
Just give me advice, ways how to store private token (RSA) or access/session token for API.
Don't hesitate to give your reaction, and tell me if I'm not exact or something else.
You need to use a token-based authentication for your REST API. JWTs are the best in this particular case.
Why Use JSON Web Tokens?
Tokens are stateless. The token is self-contained and contains all the information it needs for authentication. This is great for scalability as it frees your server from having to store session state.
JWTs can be generated from anywhere. Token generation is decoupled from token verification allowing you the option to handle the signing of tokens on a separate server or even through a different company such us Auth0.
JWTs have fine-grained access control. Within the token payload you can easily specify user roles and permissions as well as resources that the user can access.
This will be your typical authentication flow process:
A user signs up/logs in, during the login process, you generate a JSON web token from the server and return it to the client. Since you are using PHP, you can use this library for the generation and signing of the token.
Store the JWT returned to the client on the browser Web Storage(local/session storage). It can also be stored in a cookie.
For subsequent HTTP requests from the client to the server, you send the token via headers/query, then the server validates the token. If it's valid, the user is authenticated otherwise the user is rejected.
BTW, if you don't want to implement authentication yourself, you can use Auth0, check out VanillaJS SPA and PHP quickstart
I hope this information helps. Cheers!
Authenticating REST API's with JavaScript front-ends is difficult because the JavaScript code is completely readable by anyone visiting the site so storing any kind of login credentials is no good.
With a standard Server to Server set-up simply using basic auth over HTTPS is more than enough but basic auth is no good for JavaScript SPA's as the credentials are in plain view.
For SPA's you need to be looking at JSON WebTokens, as your back end is in PHP you need to be looking at PHP-JWT from firebase. You can get the code here: https://github.com/firebase/php-jwt or recommended using composer:
composer require firebase/php-jwt
The package makes implementing JWT super simple see the docs for a complete code example. Also check out the JWT for a complete break down https://jwt.io/
I suppose Jwt (https://jwt.io/) is good solution for your question.
On the client side you can store the token on the localStorage or some global variable (for SPA).
You can transfer token on the HTTP header or as request parameter. It works.
Also you can see https://auth0.com/blog/angularjs-authentication-with-cookies-vs-token/
I have a private API, where I'm using basic authentication as my security layer. Right now the API is consumed by my iOS app, so no one is able to see the key pair.
I'm creating the same app for the web now, using React and Javascript and need to consume the same API using basic authentication.
How can I use my API key pair in Javascript without exposing that key pair to the public? Is such a thing even possible?
As #Andrew mentioned, that is not possible, you can just make it harder to get, but it'll be there somewhere on the client code, and that's enough to say you're exposing it.
If you're open to alternatives, I suggest you to use a per user authentication for the first request, and then a token based authentication for further requests. That token can be a JSON Web Token and it's the flow I'm talking about:
This is the way it works, taken from JWT's official documentation:
In authentication, when the user successfully logs in using their
credentials, a JSON Web Token will be returned and must be saved
locally (typically in local storage, but cookies can be also used),
instead of the traditional approach of creating a session in the
server and returning a cookie.
Whenever the user wants to access a protected route or resource, the
user agent should send the JWT, typically in the Authorization header
using the Bearer schema. The content of the header should look like
the following:
Authorization: Bearer <token>
TL;DR: No.
If the client needs to be able to connect to the API directly, there is no surefire way to prevent them from discovering the API key, as they must, by design, be able to access it in order to send it in the request. You can take measures to obfuscate it, by storing it encoded (but the client will have to have the decoding algorithm as well).
This is in fact also true with your iOS app. Someone can reverse engineer the binary or intercept the requests and view the header, discovering the API key.
A possible “solution” is likely to have each client get their own API key, be it temporary or permanent, that is in someway locked to their account/device/session to limit reuse.
I have two separate web apps:
database API
and basic web-client (Flask) with some JS-code (Knockout.js) for interactive
features like filtering products 'on-the-fly', cart, etc.
To implement interactive answers through API I use JavaScript requests running in a user's browser. I want to control access to API and give it only to authorized web-apps, for example, my own client JS-code.
I read about HMAC and Oauth. The key point: the server and the client share the same secret which is used to generate a HMAC, for example.
But how should I generate a HMAC inside a user's browser using a secret and not exposing the secret to others? As I understand, if my JS-code has access to a secret, than anybody on the internet has that access, right?
JavaScript applications are what are called 'public clients' in OAuth 2.0. It basically means they cannot keep secrets and therefore you cannot do client (application) authorization.
So, if you are using a JavaScript application to talk to your API, you'll need to do user authentication and give users access to your API. Or switch to a server side application to access your API.
I am building an MEAN JS application,I want to protect my application clientId and client secret in clientside angularjs application.Where can I store these details.How to provide security for this?
For user login I have to provide these and need to get access token...new to this help me..
Keeping client_secret at client side, you basically ruin the whole idea behind it.
So, say, Google asks client side apps to make an additional verifying call Google OAuth docs.
If you are able to make a request from server-side, after receiving token from oauth provider pass it to server side and send token and client_secret to receive user's data.
Actually, this is much more similar to Google's hybrid auth, which is considered to be more secure than common oauth