I have 2 web apps setup in azure, both with the same clientids setup with oauth middleware. Both use the same Azure AD, with the same user I get a token and on one webapp I get a claimsprincipal but on the other one I get a windowsprincipal. Why could this be?
Related
My company's application has a website xyz.com, and the user authentication is done via Auth0 SSO. There is another service which we internally use, and Auth0 SSO is configured on that as well (hosted on service.xyz.com).
Now, this service also has a SDK (in form of JS) through which it allows us to embed its components. However, that requires me to get access to its accesstoken.
When I'm in context of our company' website (after logging into xyz.com), I can access the Auth0 token, but in order to make use of service provider's SDK and integrate that in our website, I would somehow need to get the appropriate oauth token for that service provider.
My question is, how is this usually done?
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
I am planning to integrate Azure Authentication in my Drupal 7 site. I got the Token endpoint URL, Client ID, Client secret from Azure Support team for my site URL. When i tried to connect getting below error "Access token requested for user XXXXX: FAILURE"
Thanks in advance
Girija
This error can occur for a few reasons:
The client application is not registered in the Azure AD or is not added to the user's Azure AD tenant. Ensure that you have registered the application in the correct tenant and ensure that the client id, client secret, and tenant ID in your application registration match what you have in your web.config or app settings.
The error usually can also mean you got an incorrect access token for the resource. Are you using Graph API? I have seen this error before when someone tried to get the access token for Azure AD Graph API but used that access token to access Microsoft Graph API. The same could be going on with your drupal site.
Can you please post the full error message here?
We are trying get a SaaS product to authenticate against our AD FS 4.0 services running on Windows Server 2016.
The web application is setup for SSO using JWT and allows us to setup a Shared Secret, Login URL and Logout URL
I got the app to redirect to the AD FS login screen https://hostname/adfs/oauth2/authorize and authenticate against active directory. From there it returns a code value that I know needs to go to https://hostname//adfs/oauth/token but here I'm stuck.
Do I need to build a web service that receives the code from the authorize endpoint, posts it to the token endpoint, and then redirect back to the web app with the JWT? Or can AD FS do this on it's own if I configure it correctly?
What I want is for the web app to redirect to the AD FS login screen (done), AD FS to authenticate against AD (done) and then (do magic) and redirect back to the web app with the JWT.
EDIT:
The following is what I want with Server 2016 AD FS 4.0. Will I need to create my own ADFS/AUTHORIZE->code->ADFS/TOKEN->jwt->Application URL handling service?
https://support.zendesk.com/hc/en-us/articles/203663816-Setting-up-single-sign-on-with-JWT-JSON-Web-Token-
UPDATE:
It does appear you have to have control over the client application, which is not the case when you're using a 3rd party SaaS. Therefore we need to implement a myapi such that.
SaaS redirects to /adfs/oauth2/authorize
AD FS redirects to /myapi/?code=ab2..3cf
myapi posts code to /adfs/oauth2/token
AD FS response contains JWT
myapi redirects to SaaS with /?jwt=token
This flow is called Authorisation Code Grant.
Good diagram here.
Get the code, send it to the /token endpoint, get the access token, send it to the API in the Authorisation header.
If the SaaS product has an OpenID Connect stack, it should do this automatically. The SaaS product needs to drive the flow.
Update:
The only thing you need to do with ADFS is configure it. No programming required.
You need to code the client side.
Client sends to /authorize endpoint.
ADFS responds with code.
Client sends code to /token endpoint.
ADFS responds with token.
Client sends token to API.
I have an Asp.Net Core 2.0 Web API running as a web app in Azure. My API is consumed by client applications which are windows service running on servers at various client sites. So, this is a "Daemon or Server Application to Web API" communications flow as described in Authentication Scenarios for Azure AD
I register the client application at each site as a separate unique app in Azure AD, obtain the ClientId and AppKey and send it to the respective site for their devs to use in their service to request a JTW access token from Azure AD to use in the authorization header when making an http request to my API.
This is all working just fine.
The question I have is this; is there any way, in this scenario, that I can identify which site is making the request? From what I understand, it doesn't seem like I can add custom claims to an OAuth2.0 access token, like can be added to an OIDC ID token.
If you register the apps yourself then you know all the client ids for each different site so your API could use the appid in the JWT access token (which is the client id) and cross reference it against a list of sites. Here is an example of a JWT token obtained using the client credentials grant type: