I have a site where user must login to access. I have some web services calls for getting datas stored in another server.
But to access to the server user must login again via a login popup. To avoid this I want to pass the user/password but not in the URL.
Is it possible to do this in Javascript adding user/password in header or something similar ?
Authorization of this type is typically done via request headers. For regular users interacting with a web page, the login credentials may be remembered using the cookies in the request. For API access, however, the standard way to do this is with bearer tokens included in the POST body of the request. See also: OAuth2.
For authenticating API access (but not the user), such authentication is typically done via API keys.
Important footnote: whenever doing any authentication, you should ensure that your requests are encrypted (and, when setting cookies, that cookies used for authentication are properly marked "secure").
Take a look at the W3C specifications for the XMLHttpRequest Object. The five-parameter version of the 'open' method allow you to specify the username and password.
EDITED
Keep in mind: this will make your password publicly accessible.
Related
There is a sensitive page in my website, so I want to authenticate visitors before they opening a link like: www.examples.com/builder.
I know if I use cookie based authentication everything will be simple, as the browser will send the credential message in cookies automatically. But in my situation, I have to use token based authentication. Browser don't send token if there is no pre-load script.
So my question is how to achieve token based authentication when someone open a sensitive page directly.
As far as I can understand,
you're looking for a way to avoid double roundtrips to send authentication headers to your web-service.
If I am correct, then this would only be possible via service worker which is a not widely supported feature. https://developers.google.com/web/fundamentals/primers/service-workers/
If, depending on your requirements, you can't go for service workers, then, the only left option is to use cookies.
I normally have a secondary authentication flow which uses cookies allowing a web service to authenticate a user on its first get request (the one made by the browser).
There are also some spa framework which implement routing resolvers but this will require a double roundtrip (1. load javascript, 2. send the token).
I own a Play Framework application acting acting as a backend server providing a set of REST APIs.
At client side, I own an AngularJS application that calls APIs from backend-server through AJAX.
Currently, I make use of a solution based on Session-token mechanism.
Meaning that each time a user logs in successfully, a cookie is retrieved at client side containing an authentication token.
At each request then, the cookie value (the auth token) providing by the client request is extracted on the server and if valid, the request is made.
Now I want to use OAuth 2.0. Reasons are? :
It's a great standard way to secure API, avoiding the use of a datastore (Memcached) to keep auth tokens at server side, as I'm currently providing.
I want to provide a better secure than a sole cookie, by providing some client_secret and nonces to avoid some replay attacks etc...
I want to restrict the amount of clients capable to call even public REST API I provide, meaning API that allows anonymous call, like listing a list of items for instance.
The point is that I don't involve a third party, since all protected resources are on my own.
I came across this article explaining how to secure internal REST API with OAuth 2.0 implementing a 2-legged instead of a 3-legged as usual.
However, I can't figure out how the Client Credentials flow could authenticate a specific user, when calling for a REST API that needs to have a user authenticated.
Indeed, Client Credentials flow seems to be based on a global client_id, client_secret keys (global to the app, so in my case to my Javascript app), and therefore not enough specific to target a specific user and controller its specific rights.
Any help would be great.
Seems like you should use "Resource Owner Password Credentials Grant" (https://www.rfc-editor.org/rfc/rfc6749#section-4.3). It is dead simple - put client ID/secret in Authorization header and put user name/password in query variables. Here is an example from the RFC:
POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded
grant_type=password&username=johndoe&password=A3ddj3w
Server side you can check for both validity of the client (your javascript app) as well as the user. Just remember that it is impossible to protect the client credentials as it will be embedded in your (downloadable) JavaScript code. The user name/password is entered directly by the end user.
I'm fairly new to JavaScript and I'm trying to access a page that requires user authentication before that page is displayed.
How do I access this page? (I have the required user name and Password) I'm know we can use the XML HTTPrequest object to access other URLs via the script. But I'm not aware of any option that lets me authenticate first.
How do I do this?
You should probably make a request to the authentication page, sending username and password. That would set a session cookie that the browser will handle on his own, then the session cookie will automatically be forwarded to the following requests you make, until the session expiral.
Remember however about the limits of cross-domain scripting, e.g. if the page you want to authenticate is in a different domain than the one the page the script is running in is the browser will likely refuse to make any request.
Actually this automatic cookie handling from the browser is the reason cross-domain scripting is insecure and thus forbidden for most sites.
I am diving into OAuth 2.0 to protect my RESTful services. I own the consumer and the provider sides, and therefore do not need the end-user to allow access to the data on the provider. I've experimented with client credentials flow, but this appears to only allow me to get a token for my whole client, but not for an individual user. If I used the token for my client in Javascript, then it would be given to all users and wouldn't be very secure because users could potentially get data for all other users.
Is there a way that I can use 2-legged (aka client credentials) to get a user-specific token that can be used in Ajax/Javascript (similar to what the implicit flow provides, but without user approval)?
Thanks.
You're right, the standard says nothing about user credentials for the "client credentials grant" scenario. However, if the protected resources belong to users, each token should be related to a specific user. Based on your question, I think this is the case.
If you're implementing the OAuth server, too, then you can easily do this. Just add a "user_id" parameter to the authorization request in the "client credentials grant" scenario. Processing the request on the server side, you can tie the token to the specified user. You may consider this as your own slight extension to the protocol.
You may also want to be completely standard-comformant and do nothing that's not written in stone, or you may not have access to the OAuth server implementation. In this case, you may try to use user-agnostic tokens (or "whole client" tokens as you called them in your question). However, accessing the protected resource, you must explicitly specify the user (e.g. as part of the resource path or in a query parameeter using HTTP) since it cannot be deduced from the token itself.
I discovered the ability to auto-approve clients, so the user does not have to authorize when certain clients access their data. This works in my scenario because I am using the same single sign-on mechanism for both websites, and the login to the provider is transparent to the user.
I'm developing an API where a website owner submits their website url to a database, when the user uses the API the javascript hostname gets sent to our database and gets checked against the string they submitted when registering. Is it possible for a malicious user to spoof their hostname? If so, are there safer practices?
Anyone can send an arbitrarily constructed HTTP request; the referer headers or the properties of window.location cannot be trusted (even if the user cannot change the contents of window.location in their browser -- at least not without causing a navigation -- the user can always observe what requests get generated as a result of that value, and then send an HTTP request with that altered).
If that will be an issue, then you will probably want to use digital signatures along with the domain to ensure that the domain has not been altered (i.e., changing the domain without changing the signing token will render the request invalid, and generating a signing token from the domain is not obvious and requires some server-side backend mechanism that you provide to the customers of your API).