8.3 - vote for OAuth support for exposed REST services.

aware_support

As you probably know Aware IM allows you to expose REST services. However, unlike consumption of REST services, exposed services do not have support for security (OAuth).

It's quite a lot of work to support OAuth for exposed services. Our question to you is how useful would this feature be for you. Please vote yes or no.

Jaymer

yes - this will enable me to offer a solution for corporate IT needs

Jaymer

FWIW,
here's a Node.js OAuth2.0 server implementation

This would allow Bruce, for example, to expose his client's POs, Ordering, etc. to their customers and vendors.
He would use JS to code, parse, etc. all the requests and post directly to the database (which bypasses any Aware business rules).

Question: If Aware DID NOT have this [security] built into it, what chance would Aware have of being the solution for his client?
or... if Aware doesn't offer the highest level of REST security, they'll do it in another tool.
So, if we [ie. Vlad and team] don't do this now, then how many more future opportunities will be missed by us [developers] and Aware?

(cross posted to the REST Vote thread - unsure where the best place for this is)

customaware

+100

Jaymer

LOL
30 minutes before you posted this, I wrote Himanshu the following email:

hi
please respond to this thread

aware_support

With all due respect, the security should be added ONLY if the REST implementation supports true REST standards that any app or system can use Aware REST service as if it was written in Java or Node or .Net and etc.
If it lacks features and we can not truly use it, then the whole OAuth work and resources will be waste of time, because it's not usable.

Sorry, I really have no idea what you are talking about. Why doesn't current Aware IM REST implementation support "true REST standards"? What standards are these?

We certainly have clients who use current implementation irrespective of the "standards".

aware_support

What is this document, Ben? It contains some fragments of some guidelines, which come out of nowhere. Are these the official standards approved by a relevant authority? Is there a formal specification?

By the way, Aware IM already follows whatever recommendations this document has.

From my experience (rather extensive) of working with REST there are no standards. Every vendor (FB, Google, Dropbox etc) seems to do whatever it pleases. And there is not much scope for variation in REST anyway.

johntalbott

There are many REST best practice resources that prescribe the same basic fundamentals.

-HTTP verbs - GET, PUT, POST, DELETE, PATCH
-CORS (Cross-Origin Resource Sharing)
-JSON input
-Standard Response Codes
-Filtering, Sorting, Paging
-OAuth
-API Versioning

REST Best Practices References
https://github.com/Microsoft/api-guidelines/blob/vNext/Guidelines.md
https://github.com/tfredrich/RestApiTutorial.com/raw/master/media/RESTful%20Best%20Practices-v1_2.pdf
https://www.ibm.com/support/knowledgecenter/en/SS4GCC_6.1.1/com.ibm.urelease.doc/topics/rest_api_ref_conventions.html

aware_support

There are many REST best practice resources ,,.

These are just best practices. Nothing stops anyone from using current Aware IM REST services.

Let's not digress. This thread is about OAuth support for exposed services - whether you will use it or not.

ACDC

The REST service is one of the main reasons I will be upgrading to 8.2 shortly. I have third party corporate service insurance providers wishing to access confidential member record data, security is key here and OAUTH is definitely part of the equation. Not only will this provide security but also present a professional image and let me mix it up with the big dogs

x 1000

weblike

ACDC wrote
The REST service is one of the main reasons I will be upgrading to 8.2 shortly. I have third party corporate service insurance providers wishing to access confidential member record data, security is key here and OAUTH is definitely part of the equation. Not only will this provide security but also present a professional image and let me mix it up with the big dogs

x 1000

Well said.
Combined with the fact that last year GDPR came to our lives, I don't know others outside EU, but here every website, online app has to meet these regulations. Defenetly the security it's a must.

aware_support

Support, I have searched ALL the docs about "Exposing" Aware's resources via REST service and I can't find anything.

This is documented in the HowTo document. There is also a video tutorial in the "Web Services" section.

If we implement this feature it will be fully integrated into Aware IM. You won't have to worry whether there is a special "server" or not. When you expose a service as a developer you will just tick some checkbox whether OAuth is supported or not. If this checkbox is ticked Aware IM will expect an access token to be provided in the HTTP header when this service is called by a 3rd party. Aware IM will automatically validate this header and refuse to execute the service if the header is not there or is invalid.

To get an access token a 3rd party will need to register with the owner of the application. To do this they will need to call a special URL where Aware IM will provide a special UI to register a "client". Then Aware IM will automatically generate "client key" and "client secret". Before calling any secure Aware IM REST service the 3rd part will need to authenticate itself first and get an access token, that he should then provide for each service call. To get an access token the 3rd party will need to call another special URL that Aware IM will provide and specify their "client key and secret".

That's in a nutshell how it will work. At least, this is the idea.

aware_support

The statement in RED, How are you going to provide this UI since the client could be running in iOS (Flutter or Objective-C) or Android (Java or Flutter/Dart) or some JS library like React or Angular or Ionic..

No. Client ID and secret should only be obtained ONCE for a particular third party client. The UI will be a standard web desktop form (which may work on a mobile as well).

Secondly, what do you mean third party? Are you saying Aware isn't going to be the original authenticating user system? How does this third party going to authenticate that user, if the user is stored in Aware DB?

You really need to read what OAuth protocol is. A third party is any external applications who will be calling REST services of your Aware IM application. A third party needs to obtain its client and secret first (done only once) and then present these to get an access token from the Aware IM-based application.

aware_support

If the User's credentials are stored in Aware DB (i.e. User ID and password) how is an outside third party authenticating service going to reach AwareIM DB to authenticate that user?

I really don't understand what you are talking about. User name and password have absolutely nothing to do with this. Aware IM will store user id and secret. This is not the same as user name and password. This id and secret are well known to the third party (client) - they are given to him explicitly.

PLEASE read the documentation about the OAuth protocol and let's not continue this discussion on this forum thread. It was not meant to be a discussion about OAuth details - just whether or not it will be useful to developers.

himanshu

Hi Everyone, here are my 2 cents on this topic.

OAuth is a framework which will really help users to take advantage of it without getting into the complexity of Authentication and Authorization. Yes, it will be great features if we have in AwareIM. This will not only opens the door of more possibilities where I can imagine running multiple AwareIM apps/3rd party apps and they can call each other API with the same authentication/authorization flow.

Currently, We are using JWT(JSON web token) in all our API for authentication much before version 8.0, when consuming REST API not exists. Example: every time when a new user register/login himself system create a new unique token which is used for calling API. A Token is saved on server and client side (native mobile) and later used every time for every request which authenticates and custom development we have a capability to control the flow of data.

There are still some drawbacks or limitation when we exposed REST API under AwareIM.

Below are the few of them

All attributes values get exposed if we want to return object limited attributes only. This is major issue which has other problems if you have large business object.
Multiple responses cannot be paged
All are GET API, POST API is recommended for sending data from client to server.
Not able to send credential data under using Authorization Header.
Not able to upload a document or any file today.
When there are multiple records and API request does not have any data, No way to define response.

There are still few tricks which help we can to achieve responses from AwareIM API.

RLJB

+100

It's an obvious addition and much needed requirement. We will use it.

I find it hard to imagine most forum users with customers who are businesses wouldn't need/use it. In 2019 most leading business applications will get asked "do you have APIs?" ... with oAuth we could publish an open API on our Aware written platform, with great documentation and maintain competitive advantage.

For anyone who thinks they don't need this, I would like to hear what your app does and who your customers are, tell me over a beer at the Portugal conference and I'll see if I can change your mind.

thanks for suggesting it Support.

aware_support

Good news for those who need this feature. It WILL be included in the next version - we have done most of the work already.

weblike

aware_support wrote
Good news for those who need this feature. It WILL be included in the next version - we have done most of the work already.

Awesome support..Excellent news, Thank you

customaware

Good Job Support... Well Done.

tford

Once again, support listens + delivers on a timely basis .. a formula that far too many organizations manage to not accomplish.

Keep up the great work, Vladimir!