I was trying to authenticate a user using EB's loginWidget example, and as I debug,
I discovered that getAccessToken() request always returns a null
even though a session was successfully created.
The parameter I passed in to the loginWidget are: user secret I got from the app key, and the app key.
Are you using PHP? If so, this guide should have you covered:
https://github.com/ryanjarvinen/eventbrite.php/blob/master/OAUTH2-README.md
By default, PHP's $_SESSION store will be used to save each user's access_token. You'll need PHP session support to be enabled in order to get the basic demo working:
https://github.com/ryanjarvinen/eventbrite.php/blob/master/OAUTH2-README.md#2a-using-phps-built-in-_session-storage-optional
PHP's default $_SESSION storage definitely has a few trade offs. If it is not your preferred data storage system, you can provide your own data-management callbacks, allowing you to store the access_token in a cookie, in your database, or in any other location that works well with your system architecture. More information is available here: https://github.com/ryanjarvinen/eventbrite.php/blob/master/OAUTH2-README.md#3-define-data-management-callbacks
Here is a basic implementation example, which takes advantage of the default $_SESSION store:
https://github.com/ryanjarvinen/eventbrite.php/blob/master/examples/oauth2-login-example.php
Related
I have a Core3.1 web application protected with azureAD (OpenIdConnect) and I retrieve most of the user's related data I need, from the idtoken:
Username, email, employeeId, even the user's AD groups.
I also need to get some additional data from the database and I'm not sure how I should store this data in the application, to make it available everywhere and for the entire time the user is logged in.
I don't want to use cookie. For now, I used the session.
Problem is this session expires differently from the authentication session, so I had to call a static method to check if the variables are empty and eventually doing the query again.
It works... but is ugly.
I feel like I'm supposed to handle things differently but I don't know how.
A claims based solution can work best here, where you:
Define a Claims Object in your API
Populate it when your API first receives an access token
Cache the claims object for subsequent requests with the same access token
This cache will always be in sync with the user session
See my blog post for further details on the pattern. And here is some implementation code.
Using the OktaSignIn widget, I see I can get res.session.token. Can I use this (or some other attribute) in another app -- with the APIKey -- and validate that this is a valid session?
We just want a simple to use auth system and don't want to set up OpenAuth...
Can't seem to find any APIs that do what I need.. but could have missed it of course...
Edit. Basically... our front end uses the OktaSignInWidget... then we want to use this in a Bearer token our API Services layer can validate.
Thanks!
Looks like this will work...
/api/v1/sessions/me
Get id from this.
{"id":"102wtHeHhr4Q4q4rh2Fjy6pGA","userId":"00u9uwkfyfiz3Y7uk0h7",
Then... this can be passed and using the API key...Issue a GET to...
/api/v1/sessions/102wtHeHhr4Q4q4rh2Fjy6pGA
Returns...
Session...
The call to /api/v1/sessions requires the API key -- which is fine.
As you mentioned, you can use the session id to see if the session is still valid on the Okta server by:
Exchanging sessionToken for okta session
After redirecting back to your app, calling /api/v1/sessions/me to get the sessionId
Using that sessionId in the request to /api/v1/sessions/id with an apiToken to see if it's still valid
This will exist as long as the user has not logged out of Okta, but the browser state might be different - for example, the Okta session cookie will normally be deleted when the user's browser closes, while the session might still exist on the server.
Alternatively, to check if the browser session still exists, you could make the validation check on the client side by making the request to /api/v1/sessions/me - the one gotcha is to make sure that CORS is enabled for both the domains your apps are running on so they have permissions to make this request to Okta.
The above methods work, but it does sound like what you should be looking into is Okta's API Access Management (OAuth2) - it was designed for this type of flow (passing Bearer tokens to your API services layer).
Here is the situation, I have setup 2 codeigniter installation.
One will be a client and one will be an api. Further improvement of this will be
The client will no longer be made from CI, since I wasn't using it's functionality. I just wanted to start out from a mvc framework right on.
My question would be where should I be storing sessions? during logins.
Below is how I did it, but I think I did it wrong.
I created a Login from the client. This one sends the login credentials to the api and then validated these information sent by the client and will return a message/response whethere the login credentials were valid or not.
If the login details were valid, the api will set a session in it's controller like this
if(true) {
$this->session->set_userdata($array);
}
This is in the login_controller I created. Is this the proper way of setting sessions for a client of a api?
You've got the concept right. You only want to set session userdata upon verifying the user supplied valid credentials.
That said, make sure you're using encrypted cookies and, if you're handling sensitive data, store your session data in the database. Storing it in the database causes some odd quirks with how sessions work in CodeIgniter (mainly with flashdata), but the added benefit of positive identification might potentially be worth it.
By storing the session data in the database, you can more positively verify a user is who they claim to be (in terms of the session ID, etc). The reason is because the session data is stored only in the database, and not in the session cookie (which only holds session ID and some other info). That way, even if someone does manage to decrypt the cookie, they can't modify their userdata to pretend to be someone else, like you might be able to with the cookies only method.
As the manual says:
Note: The Session class does not utilize native PHP sessions. It
generates its own session data, offering more flexibility for
developers.
But when I store some data using $this->session->set_userdata(array('sample_key' => 'sample_value'));, in phpinfo() I can find sample_key and sample_value in that.
I hoped that the part
does not utilize native PHP sessions
to be meaning that it hides the session variables from phpinfo().
I'd always thought that it might be a security lack. Could it be?
As it seems, the values are urlencodeed.
CodeIgniter's "session" just stores the data in a cookie, and calls it a session. Native PHP sessions store the data on the server, and a "sessionID" in a cookie.
In phpinfo, you can see the variables, but it's your session, you can't see another user's session.
Why does Codeigniter do this? I mean isn't it very insecure if users can see which data is stored in their session? And and what if they change a value in the cookie?
Well, it's data about the user. If they want to change it... so what? I don't see how it's "insecure".
You can encrypt session data, or use databases for session data integrity verification.
The documentation is your friend; use it.
For what it's worth, it does seem daft that native PHP sessions aren't used. The documentation claims that this offers "more flexibility" to developers, but given the caveats listed on that page, I can't imagine how.
Storing session in Cookie is a worst practice, every browser has a size limit for cookie and cookie is a thing which get send every time with your request, though it is simple ajax request, this practice will only make your requests slow, I think while developing session library for Codeigniter they might hove thought, that user's will only store small amount of data in session, but its simply stupid idea to store a session in Cookie
check this out: https://bitbucket.org/xperez/core-session-storage-for-codeigniter
its a wrapper for ci_session interface with native php sessions and thus works also with memcached and not DB.
Cheers
Well, Codeigniter's out of the box interpretation of sessions is different to that of PHP sessions. You can still use PHP sessions if you want via the $_SESSION super global, but Codeigniter basically treats sessions as more convenient cookies. Although, you can make your sessions store in a database which is what I do and will prevent a user from changing session values.
If you want semi-secure session variables, use the in-built PHP ones if you don't want the hassle of making Codeigniter store session values in a database encrypted.
Everything is explained in the detailed documentation: http://codeigniter.com/user_guide/libraries/sessions.html