We currently support mobile and desktop apps. Our product is somewhat unique. We have our own secure authentication method. However, I've been tasked with integrating Okta to validate credentials in a customers ActiveDirectory. They currently are Okta customers.
Ideally what I would like to do is program our windows .NET client to authenticate user credentials and then pass some information (securely) to our server application such that it can validate the session and then make further calls to the API to obtain user attributes.
We don't currently send passwords in the clear to our server. We use a hash and then just compare the incoming hash to the persisted hash. It seems the easy way to solve this problem is to just allow clear text passwords and then have the server authenticate the user and do all the work and just pass back our own token as part of our usual process.
Is there a way to get a SAML token on our client side to validate on the server side and get access to Okta? Would I have to generate a SAML assertion on the client side and pass the response up to the server?
If you have a .NET application, are you able to enable it with WS-Federation? If so, then you can then follow: https://support.okta.com/help/articles/Knowledge_Article/29510977-Configuring-the-Okta-Template-WS-Federation-Application
Reference: http://developer.okta.com/docs/guides/saml_guidance.html#reference
Related
I have the following scenario that I am curious if it is possible to implement. I need to use SSO and more specifically OneLogin to authenticate the user via custom UI from my Java standalone application. I know this can be done via Create Session Login Token and then Create session via token One Login API calls. With some parsing I can get the session cookie out of the last call and store it.
Now I need to programmatically hit the API server, which is to be build still and this server somehow needs to validate the session cookie that I am going to send along with request. The key word "Programatically" as in there will be no browser
OneLogin doesn't provide SDK to validate existing session cookie => it would be nice if I could, based on session cookie find out if it is still valid and what is the user name used for this session. If session is invalid API server would return unauthorized.
Is this even possible? Or is it possible in some other way?
Basically One Login is already used in our ecosystem and I have to continue using it
The app that will log user in and get the session cookie may not be the one calling the API server. This could be another java application that would receive the session
I guess what I am looking for is Validate Session equivalent from Open ID Connect API in general API
The session_token that is returned via that API has a short expiry is only intended to be used for making the Create Session request which returns session cookies.
It sounds like OpenId Connect might be the best option for this use case. If you have user credentials then you could use the Resource Owner Password Grant flow to authenticate the user and obtain an id_token.
The id_token is a JWT containing user details can then be verified for authenticity by checking its signature, audience and expiry claims. It can also hold other custom information about the user that may be used by your backend application.
We would like to enable WeChat Login on our iOS client that is connected to a Parse Server backend on Heroku. From reading through the PFFacebookAuthenticationProvider, it seems that we need to write a custom authentication provider for WeChat.
WeChat Login is based on OAuth 2.0. It works as followed:
1. From our app, an authorization request is sent to the WeChat app installed on the same phone. WeChat app is called to the foreground.
2. After user approved the authorization request, a code (NOT the access token) is sent to our app.
3. With the code and our app id and app secret, our server can then call WeChat API and get the appropriate user id and access token from WeChat. This step has to happen on our server, as we cannot include the app secret within our client app.
On the WeChat documentation, it is strongly recommended that we keep the access token strictly in the control of server (anyone with the access token can make requests to WeChat API and it will be counted towards the usage limit for our API calls).
If we are to follow this practice, we cannot save the access token in the authData field of the user. Would it be acceptable to save only the code and id from WeChat into the authData and save the access token to another class that only the master key has access to? This obviously requires us to write a custom AuthAdapter for the Parse Server.
Or is there a better way to implement this custom auth? The custom auth documentation for Parse Server is pretty thin and I plan to improve it after I can get it working for myself.
You can definitely update the auth adapter to exchange the code for an access token server side. The logic would be similar to other adapters, failing to login/signup if the server is unable to process the code to access token exchange.
Here
https://github.com/parse-community/parse-server/blob/master/src/Adapters/Auth/wechat.js#L7
If the authData object has that code, you can add additional logic to exchange it.
I have an api deployed to Heroku. It is currently open for everyone to see. I only want known android phones to be able to modify and access the api.
I don't want the user to have to login every time they use the app.
Can I add some sort of certificate to the phone to verify that it is credible?
Is OAuth the best approach for this?
Is there a better way to do this so the user doesn't have to login every time?
This is a fairly broad question (and hence there are several approaches). Without knowing the language/framework you are using it's also hard to give specific advice, but:
Your server can issue a cookie or token that the client can store locally for a duration. These tokens should include a timestamp and be authenticated (use a library that does HMAC authentication) to prevent clients from modifying tokens.
Clients should present this token or cookie on each request to your server via a HTTP header or the standard Cookie header.
You will need a login system to support the initial issue of the token/cookie.
Clients could also OAuth against your server (complex) or against an external service (GitHub/Facebook/Google/Twitter), but you will still need a way to track that state on the client (hence a token/cookie).
Cookie support should be included with the standard Android HTTP client, and most server side frameworks have support (or a library for) authenticated cookies.
I’m trying to get my head around how I would introduce token-based (key-based?) authentication to a web API (currently looking at Sinatra, but maybe Rails too) that would be used by a mobile client and how OAuth would fit into the picture.
So, let’s say I want to create a web service that uses Facebook for authentication and grabbing basic user data. Here, my API would be a client to Facebook’s OAuth Server, requesting an access token upon a user’s successful login to Facebook. This would then grant me access to the user’s data which I would use to create an entry in my database, storing this user-specific token with any other application information I would like linked to them.
I think I got that part right so far, but here’s where I’m a bit confused.
I think that my API would also need some form of API key to grant access to a mobile user, since I wouldn’t want to transmit and store the Facebook key on their device. Would I have to have a separate store of keys which I provide to the client to access my service? Are there any ‘best practice’ ways of doing this?
Would I have to have a separate store of keys which I provide to the client to access my service?
yes.
Are there any ‘best practice’ ways of doing this?
The simplest way would be to generate a separate authentication token on every User creation and expose that to the mobile client. Then send it with every subsequent request header.
Devise provides a simple example how to achieve that. You don't need devise for that, just provide some token generation mechanism.
#Devise.friendly_token
def self.friendly_token
SecureRandom.urlsafe_base64(15).tr('lIO0', 'sxyz')
end
This mechanism can be extended to provide more security in following ways
Being an oauth2 provider itself.
On successfull login with facebook, you would generate an :authorization_code which the client can exchange for your own Oauth2 Bearer or MAC token within a next step. Then you can send your own Oauth2 token with every request for user authentication.
See rack-oauth2
Implement HMAC token encryption.
Generate and expose a secret_key to every client after singning in. Use this secret to sign messages along with a unique client id. The server can then lookup the secret_key for the specific client_id and verify the message.
See api-auth
Background:
We are building system that required login information for all pages. the application is designed to be Restful application using codeigniter as Phil Sturgeon library.
Scenario:
- username & password is required when a user called any page [Client]
- Authentication is needed where any Api call is fired
I a bit confused how to migrate or do the above scenario, And what are approach to authenticate the application.
A simple way to authenticate users in a RESTful API is using HTTP Basic or Digest Auth. In this setting the user credentials are sent via the Authorization header in a form of username:password as Base64 encoded hash to the server.
As the principles of REST state that the communication between client and server should be stateless, the client has to sent the authorization on every request. In practice this means that you often store the credentials in a session on the client side (as you don't want to the user to enter his credentials on every request). Please note that you should only do this via an secured connection using HTTPS!
To authenticate the application you could use a token based system, such as an API-Key. This means any request would be signed using additional request parameters. If the number of applications is finite and known, you could alternatively simply identify them by their IP.
You could also take a look at OAuth.
Request the login and password for every page is more suitable and more secure(that what I do in my projects), using 'virtual' and stored session in the database may be a second solution but not a good because it will be an additional charge for the DB.