I have an application that uses REST API and I'm implementing Digest Authentication for the security scheme. The problem is, when I log into the application, I don't want the default user/pass windows to pop out every time a resource is consumed, but instead I want it to use the username and password that was written when logged in using the app log in form, so how do I do to use that information when the first 401 status response is received?
You should pass the authentication information in the request headers when the request is made against the resource.
Related
I am working on SAML authentication for my application which has the following architecture.
Frontend application written in Laravel - does not handle authentication
Backed API also written in Laravel which handles authentication
What I have now is a login form that has a login with SAML button which uppon clicked redirects to a Microsoft page and redirects a callback page on the frontend application with information from the saml request.
Now I need to authenticate the user and create a token, then make a session in the frontend application.
Since I was using SAML, I have no password to do a traditional authenticate.
This would mean that I need some API to which I pass some info from SAML to be able to check whether that email exists in the db and subsequently created a token.
But since this API is public, I can't just pass an email because that would allow someone to guess it.
How do I prevent this?
redirects a callback page on the frontend application with information
from the saml request
the information from the SAML request is your authentication event. The user has authenticated to your application by logging in at their Identity Provider (Microsoft page) and returning to your application with their SAML attributes.
If it was a traditional authentication with a username/password, once the password matches, you would create a session for them. In this case the password check was done by Microsoft and told your application it was successful by sending the SAML Response to your callback.
If you parse the SAML Response and extract the attributes you can use one of them to create the session. Something persistent such as eduPersonTargetedID which will always be the same value for that user will let you create their session. When they logout and log back in, that eduPersonTargetedID will have the same value in their SAML Response.
SAML Response samples are available here.
I have already created an api using php slim framework. But I have an issue with securing my api. I want to access only api for the authenticated users only.
I have already added user login to my front end angular project. That is fine. But when the someone directly calls the api endpoint its show the result related to that endpoint.
For example. I have the following endpoint.
slimapi/customers/view
This endpoint shows all the data in the customer's table.
When someone types this URL in the browser. it shows all data related to that api endpoint. but I want to show some customers message when someone tries to access my api endpoint without using front end application.
You can Manage JWT Token
when client sends you login request and if login request and credential matched then you give the client a token. Then After every request, you check the token is it valid then you give the access.
just see the documentation of JWT
https://github.com/tuupola/slim-jwt-auth
You could use the OpenID Connect protocol (based on OAuth 2 and JSON Web Tokens​).
But this would maybe an overkill for the most scenarios, because a JWT would only makes sense if you have to scale the "session" over multiple servers and/or load balancers in the back-end infrastructure. Also a simple logout is not possible with JWT based tokens. If you start to manage JWT blacklists on the server-side, the API will not be stateless anymore.
I think a very long API-Token within the HTTP header, e.g. a UUID, would be secure and good enough in the most cases.
The HTTP Authorization request header contains the credentials to authenticate a user agent with a server, usually after the server has responded with a 401 Unauthorized status and the WWW-Authenticate header.
Syntax:
Authorization: <type> <credentials>
Basic Auth
Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l
Token based
Authorization: Bearer eyJhbGciOiJIUzI1NiIXVCJ9...TJVA95OrM7E20RMHrHDcEfxjoYZgeFONFh7HgQ
UUID as Token
Authorization: Bearer bb79dfb5-17fd-4ebc-acd5-548e308e5f9a
Also make sure, that all API request are SSL (HTTPS) encrypted.
PS: If you just want secure your API for a web application, a classic Session with Cookies is also good enough and very secure.
So I am trying to implement Google Login in my application. On the client side I have an android App and a web app which interact with the restful API server in PHP (Cartalyst Sentinel 2.0 for authentication).
I am facing multiple issues.
REDIRECT URI
//setting up google api client
$client = new Google_Client();
$client->setClientId($CLIENT_ID_WEB);
$client->setClientSecret($CLIENT_SECRET_WEB);
$client->setRedirectUri($redirectUri);
$client->setScopes(array('https://www.googleapis.com/auth/userinfo.email','https://www.googleapis.com/auth/userinfo.profile','https://www.googleapis.com/auth/plus.me'));
To instantiate the client I need to provide redirect Uri. Now in the case of the client being webApp there seems to be no issue as I am providing the same redirect URI at the client and server end. But when it comes to android there is no REDIRECT URI. I read somewhere that 'postmessage' as redirect uri works but didn't for me. Without the redirect URI the client throws error of "invalid json token"
Any help on this ?
cartalyst_sentinel cookie as null in the requests from web client.
There seemes to be no issue in case of normal login(api.domain.xyz/login) through credentials. But when at the server end I login the client from a different route(api.domain.xyz/blabla/google/login) the value for the cartalyst_sentinel cookie goes null even though the set cookie headers were sent as response headers.
Set-Cookie header being sent(There are two, which worries me but it works this way as well in case of native login)
The cookie is becoming null in the requests which follow after login
I have read a lot by now about these issues and have tried n number of methods but none seem to be working.
There were only two things that seemed a bit valid.
The case of redirect URI can be sorted out by instantiating the google api client with config file(google json or developer key maybe).
The case of missing cookie is due to cross domain cookies or maybe due to login being done through a nested route(sounds silly I know, but found somewhere in google).
Any help appreciated.
So, I'm trying to use PHP Http sockets to execute a rest action on a distant server.
My goal is to have my PHP script automatically execute various actions that I usually perform when browsing "manually".
The distant website is an e-commerce oriented portal (no name provided) and connection is through HTTPS (I think that may be the problem here).
[There is no hacking here, just automation!]
I manage to execute several actions with my script like logging in to the website using my username and password, adding items to my cart etc.
Using Firebug I found that the action triggered for confirming order is /createOrder, but when I try to validate my order using my script with my session cookies I get a 401 Unauthorized error (detailed below)
So I tried several times to access this action with CURL using my usual username and password but I never manage to get access.
How is it possible that I could access it by browsing manually but not with my script? Is there a way to make it work?
Response headers include:
Server: Apache
X-Cnection: close
Content-Length: 1518
WWW-Authenticate: Basic realm="WebLogic Server"
X-Powered-By: Servlet/2.5 JSP/2.1t
"The request requires user authentication. The response MUST include a WWW-Authenticate header field (section 14.46) containing a challenge applicable to the requested resource. The client MAY repeat the request with a suitable Authorization header field (section 14.8). If the request already included Authorization credentials, then the 401 response indicates that authorization has been refused for those credentials. If the 401 response contains the same challenge as the prior response, and the user agent has already attempted authentication at least once, then the user SHOULD be presented the entity that was given in the response, since that entity MAY include relevant diagnostic information. HTTP access authentication is explained in section 11."
Problem solved.
It was a cookie issue.
I was not sending the token cookie correctly.
Twitter'll phase out HTTP basic authentication by August 2010. In the link my scenarios are from Desktop Applications. Basically my client should tweet new posts on a website.
This would be incredibly simple with HTTP basic auth, because I can store and use my account's username and password in the app to authenticate.
However, with OAUTH I can get final credentials by two means:
Callback method. You are redirected to Twitter, (login if isn't), click allow access, get redirection back to your callback URL.
PIN mode. You get a link to open, (login if isn't), click allow access, receive PIN code. Use this PIN code to authenticate your app.
Do I understand correctly that PIN codes also expire? How is it possible, given a username and password just to tweet from a client application? How can a server side script log in with the username/password and click allow access? All scenarios I could google up are for a web application to authenticate via twitter where the user is in front of the browser to walk through the redirect.
All scenarios I could google up are for a web application to authenticate via twitter where the user is in front of the browser to walk through the redirect.
The user has to be there to authorise you the first time (just as they'd have to provide you a username and password), but the resulting access token does not expire and can be reused (unless the user deauthorises your application, that is).
Store the access token - it's as good as a username/password. Better, actually - if they change their password, your access remains.
The PIN does expire under OAuth 1.0a. Using the verification code returned requires use of the temporary request token in the initial authorization request.
OAuth 2.0 defines more flows - one of which uses a direct login/password mechanism. It's up to Twitter to determine which flows they decide to implement. You can also embed a user-agent in the app.
Desktop apps suffered from a really bad user-experience with OAuth 1.0 which led to 2.0. It's doable, but painful. You can request XAuth access if you need to from Twitter as well. It's almost the same as basic auth.