I'm pretty new to OAuth and API security.
I'm building a REST API that will be accessed by my own mobile application.
I want to expose API to other developers via OAuth authorization and authentication and I'll be using my own OAuth provider.
What is the authentication strategy for my own mobile app ? After all, I don't need user to authorize my app. Can I use OAuth for authentication while having my own mobile application pre-authorized by default ?
Can I authenticate users of my mobile app with OAuth or do I need something like OpenID?
I don't think you want oauth if you are looking to step over the user authorization step. If you are determined to use oauth, however, you could mask the authorization step as a login dialog or give your application an access token. User authorization is a rather big part of oauth's functionality, so ignoring it probably means you should use some other interface to access your users' information.
Accessing my own oauth REST API - OAuth is NOTHING to deal with REST apriori: OAuth - is Authorization protocol, REST - an architecture style.
For OAuth - use version 2.0 - it's 2012 already.
What is the authentication strategy for my own mobile app? - for mobile app on Android, for example, you could use could get user's account with which one registered his phone within GooglePlay store/GMAIL (and then generate one-time password from on your server side). If one wouldn't provide them to your app - make an explicit authentication.
Nowdays probably only calculator doesn't use explicit authentication - so why should you differ? You can link you Authentication to FB or Google or any other OAuth provider - what does make you to create your proper OAuth provider?
You can Authenticate users with both OAuth and OpenID.
Related
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'm new to OAuth 2.0 and OpenIDConnect
I want to ask if is it necessary to implement OAuth 2.0 and OpenIDConnect for our login, register flow of our own created client application (mobile apps and server side app)?
Because I've been searching tutorial to implement login, register flow the best practice right now is using OAuth 2.0 and OpenIDConnect but their implementation is toward to securing our API against other people client application. Is this auth flow is just used to secure another people client application to access our API?
Thank you
OAuth 2.0 is both elegantly simple or extremely complex depending on your understanding of the technology and how to implement authorization.
I'm new to OAuth 2.0 and OpenIDConnect I want to ask if is it
necessary to implement OAuth 2.0 and OpenIDConnect for our login,
register flow of our own created client application (mobile apps and
server side app)?
No, it is not necessary to implement. There are many methods of authentication and authorization. OAuth is just one of the more popular methods.
A simpler and terrible method is to just implement username and passwords for your users. Simpler, in this case, is a relative term as now you need to worry about keeping usernames and passwords stored somewhere securely.
OAuth can be used to secure public access to your website, applications (REST endpoints), and more. OAuth can be used for server to server authorization. In the end, OAuth is just a method of creating a token that is presented to a service. The service verifies the access rights of that token and denies or proceeds with the request.
Authorization and Authentication are domains that require a lot of experience to implement correctly. There are many nuances to consider. That is why so many companies are breached, they do it wrong or implement weak methods. At one company I visited for an audit, I wrote down 10 usernames and passwords because everyone had yellow postit notes on their monitors. Even the best OAuth implementation will have problems with that level of security.
The OAuth2 spec defines a Client Credential grant for machine-to-machine authorization, where a user isn't involved. Identity is confirmed via a client secret. This isn't appropriate for a native client, such as a mobile application, because stored client secrets can't be guaranteed.
Mobile apps can make use of the OAuth Code Authorization grant plus Proof Key for Code Exchange (PKCE), which allows a dynamically generated secret. This is great if you need user authorization/authentication.
However, what if you just need to protect your API's resources so that only your mobile app can use it, but you don't track users? That is, I'd like to get an access token for my application, instead of for a user.
It seems like Code Authorization + PKCE would work great, if only both the login and consent screens could be disabled. Just return the auth code. I was hoping to find a way to do this in IdentityServer3, but haven't.
Is there a configuration or flow that allows this? Or am I making a security mistake?
EDIT
It further seems to me that using PKCE should allow for a flow with two backchannel calls, one to the authorize endpoint, the other to the token endpoint. Essentially, Code Authorization without the browser redirection. I know such a flow isn't in the spec, but am I right? Regardless, the question remains, how to authorize a mobile app using its own account, not a user's?
We're building a new app that requires access to specific customer data, and OAuth appears to be absolutely perfect for our requirements - long-lived access tokens, ability to grant access to specific resources or scopes, and so on. We are not looking for 'log in with Facebook' type capabilities here; we want to expose a single, specific OAuth authentication server based on our existing customer login database, and allow web and native apps to authenticate users via this endpoint.
I've been looking at the DotNetOpenAuth code samples, and it appears that all of the OAuth 2 examples use OpenID to perform the initial authentication and then use OAuth to actually authorise access to resources.
My understanding is that you can use a 'no-op authorisation' to perform the initial authentication, allowing you to use OAuth2 for the whole process; since we don't want to support federated authentication, OpenID doesn't actually offer anything, and so I'd rather stick to a single protocol for simplicity if possible.
Is there a good example anywhere of a pure OAuth2 authentication server built using .NET? Have I misunderstood the example code supplied with DotNetOpenAuth? Or is OpenID still required for the initial authentication phase?
There's no coupled relation between OAuth2.0 and OpenId.
You can implement your custom login strategy in your OAuth2.0 implementation.
Since you gonna be the "Resource Owner"(as far as I understood your application owns the user base), you can simply replace in the DNOA authorization server sample the openid login with the standard asp.net login.
OAuth2.0 protocol simply needs to verify a user identity in order to emit an access token: how that identity will be verified is totally up to you.
I'm creating an app for iOS that consumes an API I've created, which requires authentication and authorization of users. I'm thinking of using OAuth to let the mobile users do this with Facebook. This is an internal API that isn't meant to be exposed to third parties.
Anyway, I'm a little confused about the abilities and limitations of OAuth consumers versus OAuth providers. Basically, I want to implement "Login with Facebook" functionality from the iOS app. It seems to me that this implies that my API should be an OAuth consumer, but the problem with this is that the login flow for a web app assumes a browser -- an NSURLConnection instance isn't going to know what to do with an HTML login page, and even if the redirect to the login page was made to work by prefixing the redirect URI with the fb:// schema, surely the login form is going to pass the authorization token back to the iOS app and not my API?
So my question is: is there a way to implement my API as an OAuth consumer? If not, and I should implement it as an OAuth provider, what does logging in with credentials from another provider like Facebook even mean?
I think things are a bit mixed up:
OAuth is to Authenticate your app against facebook. A user grants
access to his FB account to your app on behalf of him
"Login with FB" is the other way round and is not OAuth: A User
with an FB account is using this data to register AND login to your
app.
The entire flow of the # 2 can be read here.