As stated in the title, I'm currently trying to implement the Ajax version of Jasny SSO
I got my SSO server setup in a.com, which also has a broker setup and I've got another broker in b.com
When using only browser redirect, I can see in the sso server logs
Broker request with session {"broker":"brokerAName","token":"a","session":"a"}
Broker request with session {"broker":"brokerBName","token":"b","session":"a"}
And everything is fine.
But when I do an ajax call for the attach from b.com , I see the following log in the SSO server
Broker request with session {"broker":"brokerBName","token":"b","session":"c"}
So the issue here is that it has attached me to a different session ID (the c one) but I excpected it to attach to the a session
I followed the implementation of the demo/ajax-broker and I'm really wondering what I did wrong.
Any help would be appreciated !
Thanks !
I am making a php web application which is interacting with server through rest api
I am confused that if a user enters correct login credentials then how then what response should be returned with rest api and how I use this response to login user into my application by setting sessions and cookies.
I can't store anything on rest api server side becauese it is stateless.
then how I validate which user logged in and how I make it secure on client side.
I have a hybrid SPA php web application that makes calls to a remote REST API for all it's needs. I'm starting to implement token authentication between the web server and api and I'm not quite sure how to handle expiration of the token. There may be some flaws in my design as well.
User submits login credentials (username & password) to the web server.
Web server sends call to the API.
API looks up creds., if good, a JWT Auth token is generated and returned to the web server where the Token is stored in a php session variable. The token is never made public.
Each call the web server makes to the api sends a request with an authorization header that includes the token pulled from the session.
My problem is, what's the best way to issue a new token if one has expired during an incoming request. The api checks each request's token to determine if it's valid and if it's expired. If the request API was GET foo/bar for example, expecting a JSON string in return, but the token has expired, what would be the expected behavior?
Hope this makes sense. Please let me know if I'm not clear enough. Have not had much luck researching this particular scenario.
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.
I'm a PHP programmer by profession. So, I don't have any idea about iOS and Android coding.
The scenario is there is one website developed using a Social Networking PHP software titled "PHPFox".
Now there are two similar mobile apps which exactly replicates the functionality of this website. One mobile app is in iOS and another is in Android.
So, I've written a set of RESTful APIs where I'm accepting the request from mobile app, parse the request, pass the request parameters to the function which does the same job for website, get the response from this function, convert it into JSON format and sent it back to mobile app. For iOS and Android app I'm using the same set of REST API files.
When user logs in, the REST API for login gets called. Eventually the PHPFox function for authentication gets called, a security token is generated along with some other user data. With every login the different security token is generated by PHPFox. This data is set into the session. Now every time I call any of the functions through any REST API file the security token generated at the time of login is verified and only upon successful verification of token the PHPFox function gets called. This verification process is done internally by PHPFox. So no need to pass the security token explicitly or implicitly to any REST API call.
Till now everything works absolutely fine.
My doubt starts from here. I don't know whether the session is maintained in iOS/Android app. So, if session on server i.e. PHPFox gets timed out then what will happen to the app? Will it crash? Will the user have to login again? If user kills the app on the device and again comes to the app, does he/she have to do the login process again?
There are too many doubts in my mind. I get totally confused with these things.
Can someone please put more focus on the issue I'm facing? It would be really great if you could explain in detail.
Thanks.
REST is sessionless for its nature. You need to generate a token when user logged in. You must save this token on your mobile client.
For every request, you need to attach a valid token in request header and check it at server side.
If token expires, the token stored on a client is not valid. So, you need to login again because of 401 response. If token it's not correct you need to responde 400.
I hope that I'm helpful for you.
Unlike web browsers, iOS and android apps cannot maintain sessions. Usually, once a user has logged in (login credentials verified from server), its login credentials are saved on client side. Then the app gets data from server using session less REST api calls. This is how mostly it is done in mobile applications.
However, if you want the server session and mobile app go hand in hand (which i don't think is a good idea), the way is
1) When the user logs in, a security token is generated on the server side and saved on both server and client side.
2) The mobile app will be able to communicate with the server as long as the security token is valid.
3) When the session expires, the security token becomes invalid. Now there must be an understanding between server and client about the response when the session is expired. Now the mobile app must redirect the user to login page again. The user will login again and then communicate with the server. This should happen every time the session is expired.
If your are using Oauth 2 for athentication, here is the common setup:
User logs in on mobile app
If the credentials are ok, the server returns the access token, a refresh token and the token's lifetime
The mobile app stores those values + current timestamp
On the server's side, a garbage collector is configured to clear expired tokens
Before making any api call, the mobile app checks if the token is about to expire (with the help of the stored values). If the token is about to expire, the app sends the refresh token which instructs the server to generate a new access token
If you want users to stay connected, the app can be configured to check the access token periodically and request a new one if it's stale
Hope this helps.
Cheers
Your server should be completely stateless, and so no session should be stored.. a REST API is effectively just a data abstraction layer with optional security (through token)
So you API expose an authentication service, which will respond with an Authorization token to be used on subsequent requests as a header, this token should be a 1to1 relation with each user, and Universally Unique. It should also have an expire time, at which point your server responds with appropriate error response requesting your app to refresh the token, which can be done either via a separate refresh token system, or requesting that the user logs in again to refresh the token.
It is the APP which should maintain the state, not the server. The server is merely there for data purposes, and so should not rely on any kind of session based authentication.
A session is "something" that lives on the server. It can be an object storing details about the user (for instance session id, username, email address...) or any other data that will be required to process future requests (such as shopping cart details, delivery address...).
That "something" is typically an object, which can be stored in memory, in a database or even serialized and saved to the file system (I believe this is the default in PHP).
So when you say "I don't know whether the session is maintained in iOS/Android app", I'm afraid that doesn't make sense. Only the server can maintain sessions.
Typically, the only thing that the client would know (web browser or mobile app) is the session id (in the form of a token or GUID). That is the only thing the client/app needs to remember and it needs to be sent alongside any request to the server.
It could be stored as a cookie and/or sent to the server as a request header.
Then the server will read the session id/token from the cookies or header and will retrieve the session details from the place where it stores sessions (file system, memory or database). That is what happens behind the scene when you call session_start().
To read more about session handling and how to create custom session handler (which might be required in your case to get a token from the request headers):
http://php.net/manual/en/function.session-start.php
You should not worry about the session from the mobile development side.in Android we use SharedPrefrence and NSUserDefaults (Flag which maintains the session locally).
I dont have any experience working with PHPFox but this is how a mobile frontend should ideally handle the issues:
Case 1: Mobile app actively talking to server:
Session timeout stamp keeps bumping up and session stays alive.
Case 2: Mobile app active without any server communication (e.g. incoming phone call, moving between apps etc.):
Server session may or may not timeout.
If it times out, next query to server will fail auth and return an error.
App consumes this error and gracefully redirects to login screen with a message toast urging the user to login.
(This happens in my banking app)
Case 3: User kills the app on device and relaunches it:
The app should store the token either in sqllite or shared preferences. (Always logged in apps take this approach)
Upon relaunch, app can query the server with the presistent token.
If session is alive, communication goes through and user can
continue. If not, user goes to login screen as in Case 2.