I would like to enable authentication using a REST (preferably POST) call in Apache Shiro. The reason I want to use a REST call is so that both a web and mobile app, as well as a 3rd party using my API can use the same authentication call, which if true would pass back 200 and a token, which would then be used as a query (or form) parameter to authenticate the next call.
Can Shiro support the above described model? I am still evaluating Shiro and learning about it.
I have used some other authentication frameworks but they required that their login page in HTML be used to obtain authentication and I didn't like that because it eliminates mobile and 3rd party use.
For third-party API use cases, you probably want to use an OAuth flow:
Illustrated Guide to OAuth & OIDC
Shiro can act as the "Resource Server", see:
https://developer.okta.com/blog/2020/05/11/java-shiro-oauth
Full disclosure, I work at Okta, and the above link is Okta specific but you could do something similar with another IdP like Keycloak.
Related
The architecture of the system is like this
User can log into the website using either username-password approach (after registration) or a google-sign-in.
I want to know how can I implement authentication and authorization for this scenario.
Here is what I am thinking of implementing :
Have an REST API server built over NodeJS and Express.
The login and registration processes are handled by this server as well.
The authentication is done by using JWT Tokens stored in the client side. And these tokens are then used again for authorization of endpoints as well.
How much secure is this approach? And how can google sign in be added to this architecture.
And also if a seperate server for making auth requests is needed as mentioned in OAuth 2.0?
It would be better if the system remains Stateless to follow the principles of RESTFul APIs.
This post that I have written might give you some insight.
https://dev.to/ralphwjz/login-management-for-spa-and-everyone-else-12o6
The post covers Github login but if you replace GitHub with google, the rest of the flow is exactly the same.
I can answer more questions once in context
We have a Web App using REST API. The REST API is based on Loopback and uses it's built-in token-based authentication. For the Web App we use forms based authentication over HTTPS, so the user has to enter his username and password which we then use to get access token from the REST API via POST /users/login endpoint.
One of our customers asked us to support single sign-on (SSO) authentication through SAML 2.0 and AD FS.
We configured our Web App as a service provider (Relying Party in AD FS) and managed to support SSO for it. The changeling part is the authentication between Web App and the REST API. The idea right now is to configure both Web App and the REST API as the same Relying Party and add new POST /users/saml-login endpoint to the REST API, so the Web App can send a SAML response to that end point and get an access token based on the claims specified in the SAML response. Everything else should work as it used to work before. Here is the flow I imagine:
Web App generates SAML request and redirects a user to the IdP login page
After a successful login the user is redirected back to the Web App with the SAML Response
Web App acts as a proxy and redirects the SAML Response to the REST API endpoint (POST /users/saml-login) where it is validated
If the SAML response is valid the API returns an access token based on the claims
Web App uses access token for further communication with the REST API same as before
Here is the question: Is it OK to implement SAML-based SSO this way? Do you see any issues or security considerations with this approach? Are there any alternatives?
I have read a lot of articles on the web and questions here on StackOverflow about how to use SAML & REST API together:
Propagate SAML Assertion Response/Security Context to downstream Services/Apps
REST API authentication with SAML
SAML and back-end REST service authentication
Attacking SSO: Common SAML Vulnerabilities and Ways to Find Them
None of them really helped me to confirm or reject the idea described above.
That sounds like a reasonable approach. I can't think of any security issues.
You're simply re-posting the SAML response internally within your application for processing. As long as you then perform the various security checks on the SAML response and assertion within your REST API, there shouldn't be any issues.
My app uses OKTA for authentication using SAML. I was able to get this up. I am also able to make REST calls to sharepoint using the username and password.
Now that I have both these set up, I would like to integrate them. I would like to use OKTA(SAML) for authentication and then would like to use the SAML token for authentication of REST calls. (I am using sipmlesamlphp library for implementing the SAML authentication)
I would like to know if Sharepoint REST API supports it and if yes what headers should I pass for the same.
I'm interested in developing a RESTful JSON data API using Sinatra, and have an HTML5/JS app consume that data API. Obviously the data API needs some form of authentication so that user Joe can only access his own stuff via the API. It would be nice if I could not roll my own authentication, and instead rely on Google/Facebook/Twitter to be the identity provider.
I've looked into OAuth2 using Omniauth and I can wire that up easily enough for traditional web apps, but when talking about securing the JSON API using FB/Twitter/Google, my understanding breaks down because:
The API shouldn't really be the thing doing the redirects for the OAuth2 flow, should it?
When the callback data from an identity provider comes through, it'd probably hit the HTML/JS app, right?
A further kink would be if I ever wanted to provide 3rd party developers API access via non-web mechanisms; the OAuth2 redirect flow business certainly wouldn't work here.
So all told, I'd have an architecture that looks like this:
[ HTML/JS client ] --- [ JSON API ] [ FB/Twitter/Google ]
|
|
[ Developer ]
In effect, what I'm after is what's here, except this is for Rails only:
sso-devise-omniauth-provider
Any pointers for doing this with Sinatra? Please use some specific examples.
Well you've sort of painted yourself into a corner. One premise of OAuth authentication is that there is a user who will take an action in an HTTP client (such as a web browser) to authenticate himself to the OAuth provider. If you want to provide 3rd party developers API access via non-web mechanisms then you cannot use that sort of authentication flow.
You need to follow the API Key pattern if you want to authenticate API clients that are not amenable to the interactive web-based authentication patterns. Somehow you need to generate API keys and hand them out to authorized 3rd party developers. Look at how Twitter, Facebook, and Google do it.
I am in the process of building a RESTful web service using ASP.NET Web API, and I am considering using OAuth 1.0 as an authentication mechanism to secure the service. Our API would also be maintaining the credentials store and would therefore be the OAuth provider. Client applications using our API would be used by end users who would have to authenticate using a username and password, so I assume the client app is considered to be an OAuth consumer. The client application would make an API call to retrieve an unauthorized request token, then send along the user's credentials with the token to get an access token.
Ultimately, I could see other 3rd party applications wanting to access our application through my API, and they would use OAuth with the redirection with our application being the credentials provider.
Is this a viable way to use OAuth? Will something like DotNetOpenAuth support this scenario?
We have decided to implement OAuth 2.0, which supports various workflows, one of which includes a Resource Owner Credentials flow that allows the client to pass user credentials to the authorization server in exchange for an access token. This will serve our purposes.