I'm struggling theese days on the possible way to configure an Authentication + authorization system to consume a REST API from a mobile application.
Scenario:
We've developed 3 independent portals for a big customer that serves several users.
To enable a SSO for the 3 portals we've implemented a SAML authentication system using SimpleSAMLphp.
Every portal has a service provider and they make assertion requests against a central IdP.
The IdP checks username and password against a database where passwords are hashed and stored during registration.
After the login, the authorization on the portals is handled by the session on the server, and so far everything was fine.
Now the customer asked us to develop a mobile application that will require the users to login and access several of their protected resources collected during the usage of the 3 portals.
We've decided to develop a frontend application using ionic that will consume a REST API made in node.js that will serve all the data (both protected and unprotected resources).
Now here comes the question: to authorize access to protected resources on the Api we'd like to use JWT to easily achieve a stateless system.
The doubt is how to perform the authentication? We've the opportunity to check the credentials directly against the database skipping the SAML process, otherwise we've to implement a solution where the SSO IdP acts as authentication provider and then when an attempt is successful the API app will get the response from the idp and then issue a signed jwt to the consumer client. Is this second way a common implementation? Is it possible?
What path do you suggest to follow? The first could be very easy to achieve, but since we're using html+js for the app's frontend, if we decide to use the second solution probably in the near future we could recycle some code from the app to modernize some functions on the web portals, maintaining the jwt pattern and consuming the new Api also on the web.
I believe that in this case will be easier to ask a token to the new api using someway the logged in user's data already in the session of the portal. Sounds possible?
I hope that everything was clear, any help will be appreciated!
Thanks
The key goal here is to code your apps in the best way, via
the latest security standards (OAuth 2.0 and Open Id Connect).
SAML is an outdated protocol that is not web / mobile / API friendly, and does not fit with modern coding models.
Sounds like you want to do OAuth but you do not have an OAuth Authorization Server, which is a key part of the solution. If you could migrate to one you would have the best future options for your apps.
OPTION 1
Use the most standard and simple option - but users have to login with a new login screen + credentials:
Mobile or Web UI uses Authorization Flow (PKCE) and redirects to an Authorization Server to sign the user in
Mobile or Web UI receives an access token after login that can be sent to the API
Access token format is most commonly a JWT that the API can validate and identify the user from
The API is not involved in the login or token issuing processes
OPTION 2
Extend option 1 to federate to your SAML Identity Provider - enables users to login in the existing way:
The Authorization Server is configured to trust your SAML based identity provider and to redirect to it during logins
The SAML idp presents a login screen and then posts a SAML token to the Authorization Server
The Authorization Server issues OAuth based tokens based on the SAML token details
OPTION 3
Use a bridging solution (not really recommended but sometimes worth considering if you have no proper authorization server - at least it gets your apps using OAuth tokens):
Mobile or Web UI uses Resource Owner Password Grant and sends credentials to a new OAuth endpoint that you develop
OAuth endpoint provides a /oauth/token endpoint to receive the request
OAuth endpoint checks the credentials against the database - or translates to a SAML request that is forwarded to the IDP
OAuth endpoint does its own issuing of JWT access tokens via a third party library (if credentials are valid)
Web or Mobile UI sends JWT access token to API
API validates received JWT access token
Related
I am reading and reading, not sure why it's so hard to properly understand OAuth2 flows, which I thought I understand, until I wanted my own server.
So I have Frontend (web + mobile app aka resource owner), my own API server ( resource server )
and I want to create my own OAuth2 server.
So assuming, that on user registration, I am registering them on my OAuth2 server, saving username and hashed password ( I also want to save organization/project name, so I can user oauth2 server for multiple projects without worry of username duplicates)
Then Frontend obtains access+refresh tokens from OAuth2 server directly with password_grant. Or should I do it through my API and use CLIENT_ID/CLIENT_SERCRET with it (is that even an option)?
With access token, Frontend then now can communicate do my API(resource server)
API (resource server) then communicates with OAuth2 to validate access token - here I am not sure what's the common name of that action authorize or authenticate ?
Once access token is expired, Frontend (resource owner) can communicate directly to OAuth2 to obtain new access and refresh token. Or again - it should go through API and do it with CLIENT_ID/SECRET ?
Currently I did above implementation, but inside my API, but idea of OAuth2 is that it is separated server. Not sure how it will benefit me other than I will be able to use it for other project, but I guess with OAuth2 I can then expose API to public.
Question is, is above correct ? can someone help me wrap it with correct OAuth2 terminology ?
The frontend apps are not resource owners, but clients. Resource owners are users of these apps. These apps are so called public clients - they don't have a secure storage for their client secret, so they must not have a client secret. Instead, they should use PKCE (kind of one-time password) with the the auth code flow.
This way, they receive a refresh token they can use to get valid access tokens. The frontend apps use access tokens to authorize their requests to your backend. Your backend should validate them.
For more info, please see the current best practices - OAuth 2.0 for Browser-Based Apps and OAuth 2.0 for Native Apps.
We have an MVC application (<myapp.somedomain.com>) .net 4.5.2 (OWIN/ADAL) that uses ADFS2016 for AuthN/AuthZ via OIDC/OAuth2. Users' credentials and attributes are stored in AD LDS. A client (X) requested to authenticate in the application via their IdP over SAML2. Is this possible WITHOUT making changes to the application?
The flow I am looking for; for this client the app’s URL would be (<myapp.somedomain.com/?client=x>). Our ADFS would recognize and redirect the client to their IdP where they would authenticate and than they would be send back to our ADFS along with some predefined claims. Our ADFS would map these claims to an Id Token / Access Token for our application to use. Am I dreaming or is this indeed feasible?
Any links to articles / documentation on how this could be achieved would be most helpful.
As #Wiktor suggests, you could add a SAML client-side stack to your app.
The other way is to federate ADFS with the SAML IDP.
When the user is redirected to ADFS, they use Home Realm Discovery to either redirect to the SAML IDP or authenticate on ADFS directly.
ADFS should handle the token conversions but you may have to fiddle around with the claims rules.
I have a authorization server which generates and store bearer tokens for username and password log in using the oauth2 password grant. I want to integrate social sign in (Google and facebook) to my existing authorization server. Since my other resources are protected by authorization server how do I generate a Bearer tokens for google/facebook signed in users ? so i can access my protected resources using that token.
Note: Bearer tokens are stored in mysql db. (Using JdbcTokenStore)
Since I already have password grant implementation, I'am glad if you can give me direction to do with the current authorization service using spring-boot and spring security.
Thank you.
There are 2 main ways to implement this:
Federation, so that the Authorization Server manages integration with social identity providers
Handle different providers in your apps, which will add complexity to both your UIs and APIs
Personally I much prefer the first option, which only requires configuration changes - and no code changes in UIs and APIs. My Federated Logins Blog Post may help you to understand your architectural choices.
It is worth doing some early technical testing to see if these steps work:
Adding an OAuth web client to Google / Facebook
Adding an Identity Provider to your Authorization Server
I'm working with a client who would like to authenticate with Active Directory Federated Services using SAML. As it was explained to me, the client ADFS server is the SAML identity provider and I simply need to provide a webview in the app for them to load a login page. Upon successful authentication the response should give authenticated metadata?
I've tried researching SAML and iOS and have only been able to find third party software which offers solutions, but no explanation of how this may be done without any third party integration into the app.
Resources I've looked into:
https://www.mutuallyhuman.com/blog/2013/05/09/choosing-an-sso-strategy-saml-vs-oauth2/
http://leandrob.com/2012/02/request-a-token-from-adfs-using-ws-trust-from-ios-objective-c-iphone-ipad-android-java-node-js-or-any-platform-or-language/
http://blog.centrify.com/ideal-solution-for-sso-across-native-mobile-applications/
https://msdn.microsoft.com/en-us/library/bb897402.aspx
Since I don't know anything about the content of this login page, how do I determine if the response has authenticated correctly? Additionally how do I extract and pull relevant information from this response into the app to store for future authenticated web service requests?
If the customer has ADFS 2012R2, it supports OAuth for public clients. Use the ADAL (Active Directory Authentication library) that supports ADFS. In this case, it will pop up a browser dialog window to do the authentication and then get a an authorization code. This code is then converted to an access token (JWT) which can then be used against a WebAPI.
I am working on a AngularJS web app and I am trying to implement single sign on. I had a nice implementation using Identity server and authorization server with implicit flow and oAuth tokens, however I need a mechanism to sign the user out of all apps they are signed into.
I am currently redirecting the user to authorization server, this then redirects the user to identity server. The user logs on and it shown a consent screen, a Json web token is then sent to the app via the query string and is put into local storage. This token is attached to the Authorization header which the web api (that is on a different domain) receives and either allows or denies the request.
The problem is oAuth has no way of singing a user out of all apps. I have now looked at WS-Federation using Json web tokens but this approach still appears to use cookies which I would like to avoid as the api and client app are on different domains.
Does Thinktecture Identity Server have any way to do this and if so are there any examples I could take a look at.
Thanks
As you already said - OAuth2 is not an authentication protocol and hence does not have the concept of (single) signout.